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

• 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 Evis > 100 MeV
• be >99% efficient for selection of atmospheric ns and nucleon decay events with Evis > 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 Evis>5 MeV
• Supernova Burst false trigger rate contributes < 10% of total data bandwidth

Data selection shall:

Data Selection Principles

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

Technical Proposal Model

The “Nominal” design

Technical Proposal Model

The “Alternate” design

APA 1 APA 150

…

Module 1

…

Trigger Primitive Generation Trigger Candidate Generation Trigger Primitive Generation Trigger Candidate Generation Module-Level Triggers

Trigger commands

Det 1 Det N

…

Module 4

Trigger Primitive Generation Trigger Candidate Generation Trigger Primitive Generation Trigger Candidate Generation Module-Level Triggers

Trigger commands

External Triggers

SN Trigger commands SN Trigger commands

[Mostly] Firmware [Mostly] Software Software Software

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 tdrift 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

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---Next Level View

Work Breakdown

We don’t have enough people to have more than a couple

• f 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