Trigger Candidates (and more) in protoDUNE and beyond David Last - - PowerPoint PPT Presentation
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
David Last & David Rivera April 8, 2019 DAQ Meeting
Overall Trigger Structure Our Candidate Approach Our “Module” Trigger for protoDUNE Simulation of Horizontal Crossing Muons Algorithm Performance Path Forward
1
2
Our efforts have been focused on the process of making these decisions in the last two stages. Candidate Algorithms Module Trigger
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
Window
3
*- Focus on Adjacency for now due to computation speed.
4
WADC Modified (due to chosen nomenclature) from David Rivera’s talk on the Data Selection Call
z x y
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)
5
Electrons in DUNE-FD Red: RawHitFinder Blue: Phil’s Primitives See backup for selection criteria
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
54,000 100 GeV Horizontal Muons (Crossing APAs instrumented with FELIX),
with SCE.
7
This is a top-down view with left as upstream. Cathode in the center.
8
Collection Wire Tick
9
Collection Wire Tick 50 us
Distribution of all non-empty APA*windows for APAs instrumented with FELIX
10
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
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
Trigger Candidate Decision/Module Trigger run as LArSoft/ROOT
independent functions in C++:
Currently an over-arching script that takes care of LArSoft/ROOT
Gut of selection only dependent on C++ standard libraries Assumed that the delivery of Primitives will be channel-ordered (sub-
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
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
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
16
17
MOST IS IN OVERFLOW…
18
19
20
21
22
23
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 does not include any time necessary for sorting of any of the
primitives into the necessary groupings for selection
25
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
Outdated due to new
approach to classifying efficiency
Still points to the main issues
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