|
|
| Line 3: |
Line 3: |
| | Historical notes on the design and planning have been moved to the page "[[ DQM notes]]" | | Historical notes on the design and planning have been moved to the page "[[ DQM notes]]" |
| | | | |
| − | = Evolution of the DQM plan = | + | = Documentation = |
| − | == "Original Plan" ==
| + | Documents will be updated kept on GitHub, in the "documents" |
| − | See DocDB references for prompt processing, p3s etc (cf. DocDB 1861). The short list of DQM items includes
| + | folder of the p3s repo: https://github.com/DUNE/p3s |
| − | * 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)
| |
| − | | |
| − | = 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|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
| |
