DQM notes

Overview

Up-to-date technical information about configuration and testing of DQM software is kept the page "DQM payloads". What is presented below is a collection of notes previously used in the development of DQM for protoDUNE. This information is not actively updated and should not be used for development.

The original requirements for DQM were published as DocDB 1811. Over time, there was more detail added to some of the DQM components and their expected functionality.

Evolution of the DQM plan

"Original Plan"

See DocDB references for prompt processing, p3s etc (cf. DocDB 1861). The short list of DQM items includes

• ADC/FFT with variety of aggregation modes (e.g. APA, board, power supply etc)
• signal processing (filtering, de-noising, deconvolution etc)
• some (unspecified) fast recontruction and event display

Beam Instrumentation

Early 2017: additions by Flavio et al. Need to monitor BI itself and also match tracks to the TPC.

Comments and questions:

• pLAPPD ToF will be joined with the “normal” DAQ data stream
• The fiber tracker data, other spill-relevant data, and ckov data will go into the BI DB
• When and how to capture BI data from the DB? (Current thinking from J.Paley - purely offline, from CERN DB without own cache - any news on that?)
• When and how to merge it with the TPC and other data?
• Track reco and matching to the TPC - who will do it?

Signal Processing and Basic Event Display

Mid-2017: add basic event-display-type (cf. channel vs time) of visual product before and after signal processing.

• demonstrates that the detector and software both work as expected
• similar to the original plans
• BNL team has plans for this item, leveraging signal processing experience in μBooNE, 35t etc
• Synergy with the OM group
  • prototypes such as "purity calculation" have been tested under p3s at CERN - thousands of jobs run
  • new prototype of "purity calculator" under development by B.Baller
  • the boundary between OM and DQM can be quite fluid, most software is portable
    • Generally a feature branch configured at CERN and a FCL file are all that's needed
    • ...although a simple wrapper provides additional convenience for managing I/O file names
  • ROOT and art/LArSoft are common denominators
  • Photon Detector (need more info)
  • CRT will need to be merged offline (need more info)

uBooNE

As an additional piece of information, it is useful to consider "uBooNE lessons learned" information (courtesy M.Mooney)

• Electron lifetime/purity every 2-8 hours. Hardware and software. Track-based, requires O(1000) triggers.
• Noise filtering + event display is important (that's on the protoDUNE DQM list)
• Removal of coherent noise allows for uncovering of more subtle problems
• Channel "health": pedestal RMS, channel FFTs
• Slow Control is critical. Mostly for HV monitoring
• Drill down from global view to subsystems
• Space Charge Effect probably not needed in DQM

People

Summary

• Photon Detector
  • Alex Himmel (have contact but need more info)
• Purity and other modules related to or derived from OM
  • OM/DRA (Bruce Baller, Robert Sulej, Dorota Stefan, new DRA members)
• Signal Processing (ADC correction, filtering etc), first look at the data
  • BNL (David Adams, Xin Qian, TBD)
• CRT (?)
• Cable map
  • Flor (CERN)
• Channel map
  • Karol, Giovanna (?)
• p3s deployment and operations
  • Maxim Potekhin
• DQM Visualization
  • David, Maxim
• Reuse of the OM visualization system is TBD (Marco?)

Need attention

• BI (Jon Paley but he has a lot of other work); need reco part; Leigh Whitehead (?)
• PD (Need to ping Alex Himmel)
• CRT (Need to ping the team)
• OM visualization tool reuse -TBD

P3S

See the p3s page

Latency

• The way the F-FTS operates it naturally introduces a delay of a few minutes between inital transfer of the data to Tier-0 and placement of the data into a directory where it's available for * processing and further transfers
• This could be mitigated if DQM ran in EHN1 using a lightweight XRootD daemon with access to the online buffer, only accounting for ~1% if total bandwidth
• There are no easy solutions outside of that, so protoDUNE needs to decide whether a lag of a few minutes is acceptable