Data Selection R&D Kickoff Josh Klein, Penn, 5/1/2018 Relevant - PowerPoint PPT Presentation

Data Selection R&D “Kickoff” Josh Klein, Penn, 5/1/2018

Relevant Requirements Data selection shall: • enable filtering of data stream so that data on disk can be limited to < 30 PB/year/40 kt • act on information from TPC, PDS, timing system, and any auxiliary calibration systems • act as a “master” for calibration systems as necessary • provide self-triggering modes (e.g., random triggers, pulsers) • provide pre-scaling for all trigger types as well as rejected data • be >99% efficient for selection of neutrino events within beam spills with E vis > 100 MeV • be >99% efficient for selection of atmospheric n s and nucleon decay events with E vis > 100 MeV • be >90% efficient for selection of supernova bursts within the Milky Way • be >90% efficient for single supernova events within a burst for E vis >5 MeV • Supernova Burst false trigger rate contributes < 10% of total data bandwidth

Data Selection Principles • Be as unbiased as possible We want to accept anything that is noticeably different from noise or radio-accidentals o (But also plenty of noise and accidentals) o • Be simple as possible Easier to model and predict or measure uncertainties on efficiencies o Likely faster o o Be as flexible as possible Particularly important given uncertain noise and instrumental environment o

Technical Proposal Model The “Nominal” design

Technical Proposal Model The “Alternate” design

Module 1 Software [Mostly] Software [Mostly] Firmware Software Trigger Trigger Primitive APA 1 Candidate Generation Generation … Module-Level Trigger commands SN Trigger commands Triggers Trigger Trigger Primitive APA 150 Candidate Generation Generation External … Triggers Module 4 Trigger Trigger Primitive Det 1 Candidate Generation Generation … Module-Level Trigger commands SN Trigger commands Triggers Trigger Trigger Primitive Det N Candidate Generation Generation

Technical Proposal Model For the purposes of moving ahead toward the TDR, we are also assuming a very simple readout model where we read ~2 x t drift for all wires for all triggers except for SN burst triggers, for which we will store many (> 10) seconds of everything. So: no need to investigate, develop, test, and document lossy (or lossless) compression or localization. [Almost] all the “bias” is in the data selection algorithms, not the channels.

Going Forward • Hierarchical nature may allow diagonalization of many tasks • Can map institutions directly onto various levels from primitives to “external” • DP/SP differences also allow some independence of efforts • PDS/TPC also pretty distinct BUT: We have about one year to put together the TDR. We currently have about five (part-time) people running simulations. We still have options for architecture/hardware which means more effort.

Going Forward [Some of the] Critical questions we must answer well in advance of the TDR: • Are there software algorithms that can satisfy our DS requirements? • High efficiency for beam, supernovae, atmospherics, NDK with < 30 PB/year/40 kt • What hardware is needed to generate SP trigger primitives? (FPGA, GPU, CPU,…) • What hardware is needed to generate DP trigger primitives? • What hardware is needed to generate trigger candidates? (FPGA,GPU,CPU,…)

Work Breakdown---EOI/Project View

Work Breakdown---Next Level View 1. Trigger primitive development and testing (SP and DP) A. Determination of primitive data (summed ADC, peak, time…?) [simulation] B. Primitive generation in simulation [simulation] C. Firmware tests on simulated waveforms [“hardware”] D. Firmware tests on (e.g.) ProtoDUNE waveforms [“hardware”] E. Software tests on simulated waveforms [software] F. Software tests on (e.g.) ProtoDUNE waveforms [software] 2. Trigger Candidate Algorithm Development [simulation and analysis] A. Supernova burst algorithm B. Beam triggering C. Atmospheric neutrino triggering D. Solar neutrino (?) triggering E. PDK triggers

Work Breakdown---Next Level View 3. PDS trigger development [hardware/software] A. Determination of trigger primitive data packets (charge, time, etc.) B. Decision on where primitive generation happens C. T est of primitive generation in candidate hardware D. T est of dispatch of PDS trigger primitives 4. Trigger candidate algorithm testing [software] A. Define framework for software candidate generation B. Define hardware environment for candidate generation C. Create sample trigger primitive data streams D. Implement algorithms on candidate hardware E. Speed tests with realistic rates F. Dispatch of candidates to module-level logic

Work Breakdown---Next Level View 5. Module-level trigger logic [software] A. Define framework for software module trigger generation B. Define hardware environment for module trigger generation C. Create sample trigger candidate data streams D. Implement algorithms on candidate hardware E. Speed and latency tests F. Trigger command generation development 6. “External” trigger development [software] A. Define framework for external trigger generation B. Define hardware environment for external trigger generation C. Create sample module-level trigger data streams D. Implement algorithms on candidate hardware E. Speed tests with realistic rates F. Development of trigger commands to send back to modules

Work Breakdown---Next Level View 7. Integrated tests [hardware/software]

Work Breakdown We don’t have enough people to have more than a couple of groups on any one task Common elements that are needed in the near term (1 month?): Trigger primitive data: • • What channel-level threshold is our target? What is realistically possible? • Is there anything other than time, summed ADC value, time-over-threshold, channel number…? • Trigger primitive algorithm: • • How is baseline determined for applying threshold and calculating charge? Is a firmware/software CFD enough, or is something like GaussHitFinder needed? • Are primitives windowed, extendable, retriggerable, sliced, framed…? • Trigger primitive simulation: • With decisions above, we need to implement this in LArSoft • Trigger candidate algorithms then can operate on these and look at efficiencies • EOIs list Colombia, Warwick, Edinburgh, Iowa S, Penn, Notre Dame---who can start tomorrow? And all of this requires some agreement on framework for study and implementation

Conclusion • EOIs have generated nice set of institutions mapped to tasks • Subtasks below these are hopefully diagonalizable to avoid duplication and dependencies • (And these subtasks probably need even more work to define). • Some things need to get started immediately and we should be clear who is actually doing tasks • We should get updates at least monthly initially on each task