Trigger Candidates (and more) in protoDUNE and beyond David Last & David Rivera April 8, 2019 DAQ Meeting 0
Outline Overall Trigger Structure Our Candidate Approach Our “Module” Trigger for protoDUNE Simulation of Horizontal Crossing Muons Algorithm Performance Path Forward 1
Overall Structure for Trigger Candidate Algorithms Our efforts have been focused on Module the process of Trigger making these decisions in the last two stages. 2
Our Basis for Candidate Decisions 50 microsecond Clustering Window (D. Rivera: DUNE-doc-9808-v1 ): Unlikely to get high pile-up from 39 𝐵𝑠 TPC Summed ADC (TADC): Total Sum of primitive Summed ADC over all ticks above threshold in one TPC Utilize maximum between two TPCs per Clustering Window Adjacency/Clustering* : Two different methods for Counting Wires hit in a time window Time Over Threshold in ticks (TOT): Single-wire, single-primitive maximum per Clustering Window Wire ADC (WADC): Single-wire, single-primitive Summed ADC maximum per Clustering *- Focus on Adjacency for Window now due to computation speed. 3
Our Basis (Visually) Modified (due to chosen nomenclature) from WADC David Rivera’s talk on y the Data Selection Call on February 15, 2019. z x 4
Candidate Side Comments for DUNE-FD Electrons in DUNE-FD Red: RawHitFinder Blue: Phil’s Primitives Current thought process: Form differential efficiency curves in visible energy for various standard particles: Electrons, MIPs, photons Define integrated efficiency curve as a function of visible energy at which differential curves are at 50% efficient Optimize as necessary to limit rates from radiologicals: OLD approach focused on this (see past data selection talks/backup for details) See backup for selection criteria 5
Our “Module” Level Trigger for Horizontal Cosmics Define “horizontal”: Crossing all APAs instrumented with FELIX. Take Candidates with high adjacency (threshold discussed in later slides) When a Candidate is issued, the end points (channel and time points) of the largest adjacency (cluster size) of wires are saved as part of the candidate “Stitch” together the tracks, and issue trigger if sufficiently crosses all APAs 6
Simulated Events 54,000 100 GeV Horizontal Muons (Crossing APAs instrumented with FELIX), with SCE. This is a top-down view with left as upstream. Cathode in the center. 7
Simulated Events Collection Wire Tick 8
Simulated Events Collection Wire 50 us Tick 9
Adjacency Distribution (Threshold 15 ADC) Distribution of all non-empty APA*windows for APAs instrumented with FELIX 10
Selection, in Detail Take All Candidates in an Event where Adjacency Exceeds (or equals) 50 Call two Adjacent-In- Time Candidates “stitched” if the following are true: Up to gap of 1 in channels hit Gap of no larger than 2 ticks in time (10 ticks if across APAs) Slope of “track” different from previous slope by no less than 5% of largest possible slope If total “stitched track” has at least 450 wires hit in both APAs (presently instrumented), issue trigger 11
Performance Present Efficiency for triggering: Primitive Threshold ADC 15: 8.08% Primitive Threshold ADC 18: 8.42% Above, unexpected (more efficient higher threshold) result being sorted out: Seems to be mostly due to mishandling/losing of a trigger candidate “in transit” to “module” trigger Therefore, hopefully not a problem with the algorithm itself Magnitude of efficiency likely due to being stringent conditions chosen to avoid fake triggers Trigger Candidate Output is generally as expected: ~54% of all non-empty windows (many in that tail near 0) 12
Assumptions/Details Trigger Candidate Decision/Module Trigger run as LArSoft/ROOT independent functions in C++: Currently an over-arching script that takes care of LArSoft/ROOT object handling/communication of algorithms Gut of selection only dependent on C++ standard libraries Assumed that the delivery of Primitives will be channel-ordered (sub- ordering in time) and in sets of 100 tick packets (50microseconds): Need to change since currently plan is time-ordered Currently characterize by start tick Assumed that the delivery of Candidates will be time-ordered and in larger groups (all within 3ms for the previous results) Easy to deal with changes in this, as well. Need better understanding of limitations in time to wait 13
Local To-Do for protoDUNE DAQ Tests Sort out the small, poorly understood issues with current code Test algorithm on random trigger data to get an idea of overall trigger rates/Limit rates as necessary Test timing with current delivery of primitives Adjust algorithms to more realistic detector effects (adjacent dead/noisy channels, etc. Sliding Windows in both Candidate and Module Algorithms, if necessary/more effective 14
Integration To-Do for protoDUNE DAQ Test Understand where/how the functions will be called in the Software Data Selector, and build accordingly Construct necessary communication pathways: Brett’s PTMP messaging for primitives/candidates Trigger Commands Promising evidence for implementation in first 2 DAQ weeks (June 10-23) Extra Testing, as possible: Characterize backgrounds in terms of selection variables so that more realistic efficiency studies can be done Get CERN accounts for David L. (noticed when I couldn’t access Jira…) 15
BACKUP 16
TADC for Horizontal Muons in protoDUNE MOST IS IN OVERFLOW… 17
WADC for Horizontal Muons in protoDUNE 18
TOT for Horizontal Muons in protoDUNE 19
TADC for Radiologicals in DUNE-FD 20
Adj for Radiologicals in DUNE-FD 21
WADC for Radiologicals in DUNE-FD 22
TOT for Radiologicals in DUNE-FD 23
Candidate Selection in DUNE-FD Studies OLD Approach of limiting backgrounds to cosmics rate (~1000/day) under the assumption that 1 candidate equals 1 trigger for the entire module Utilize “keep - all” thresholds to issue a candidate when ANY (Logical OR) of the following conditions are met: TADC greater than or equal to 7000 counts Adj greater than or equal to 8 wires WADC greater than or equal to 6500 counts TOT greater than or equal to 45 ticks This limits the rate so that no event in the above simulated distributions would pass candidate selection 24
Processing Time Processing Time does not include any time necessary for sorting of any of the primitives into the necessary groupings for selection Sample APA Data Time Processing Time Beam 424.72 min 592.97 sec Atmospherics 44.83 min 16.26 sec Radiologicals 3.85 min 15.35 sec 25
Beam Differential Efficiency Outdated due to new approach to classifying efficiency Still points to the main issues of NC/neutron-rich events failing our selection Efficiency for events known to be CC is near 1, but the sample size in this energy regime is low Visible energy defined as all energy that resulted in ionization 26
Recommend
More recommend