Data Selection WG Plans 2020/21 Georgia Karagiorgi, Columbia Giles Barr, Oxford January 20, 2020
Organizing activities: New WG Structure DS WG Co-coordinators G. Barr, G. Karagiorgi Implementation System Design R&D and testing Trigger Menu; Specification of DS Data ProtoDUNE Functionality and Format; self-trigger Interfaces, Prioritization; and ext ML including Deadtime trigger calibration handling; Partitioning Teststands: Framework UD WG MiniDAQ, application repository We have already had exchanges with institutional PIs on DS related activities, and are PP WG in the process of mapping Algorithms Offline interface commitments to the new organizational structure. Convenership responsibilities are DS CCM & expected to grow Mon organically with efforts. 2
Working Group Plans: Now thru end of 2020 With the baseline design outlined in the TDR, we are now shifting priorities to developing • the design at higher level, and demonstrating functionality and performance Overarching goals for 2020-21: • Advance DS design for DUNE FD: goal is to provide conservatism: both CPU and – FPGA option for baseline (and document, including interfaces!) Proliferate test benches for DS, including emulators: at least two more DS-functional – (CPU) teststands (MiniDAQ) by April 2020, and upgradable to FPGA for when the firmware becomes available Deploy, test, and verify DS chain functionality, incl. interfaces, and performance, in – support of design: in ProtoDUNE-SP I thru April 2020 and in teststands beyond that Continue to think beyond baseline , and in close coordination with UD group: PDS – triggers, induction plane trigger primitives, correlated 2D ROIs, ML in FPGA, … We would ask that any engineering decisions for UD not preclude any promising DS upgrade avenues As we prepare for ProtoDUNE-SP II, the DS goal is to provide a slice of a full functional • version of the system envisioned for DUNE FD (including partition functionality, EXT interfaces, etc.) 3
MiniDAQ for DS The goal is to provide a functional vertical slice of one full detector unit’s worth of • readout (1 Felix card for APA or PDS) for the purposes of DS development and testing. This teststand will serve development and testing beyond ProtoDUNE-SP I and until • ProtoDUNE-SP II, at least The plan is to construct a “blueprint” MiniDAQ setup with reproducibility as a requirement, • operational by April Planning to construct two at the moment: Columbia and FNAL (the FNAL teststand is – wider-scope DAQ teststand) Repository for code is being put together (Fermilab) and will be maintained/ – available for future teststand deployments Question to UD: Would like to better understand UD firmware status; are loopback – tests with Felix (feeding fake data, e.g. pre-recorded from ProtoDUNE-SP) possible? Would like to help establish that functionality for MiniDAQ, since this will be extremely useful for DS efforts going forward. 4
Working Group Priorities: Now-mid 2020 Near term priorities: • – Working with PP WG to finalize performance metrics for DS implementation comparisons (algorithms and hardware platforms) – In addition to ProtoDUNE-SP (thru April 2020), proceeding with construction of DS testands for implementation tests and performance demonstrations – February DAQ workshop will be leveraged to advance the DS design to higher level of detail (see next two slides) Deliverable: clear and detailed documentation of design and interfaces; identification of ProtoDUNE-SP/teststand demonstration priorities, and R&D priorities, and organization of effort 5
Priorities for DAQ Workshop: (1) DS Design 1. Baseline DS design: Module Level Trigger : Trigger logic (algorithm) outline, Trigger prioritization, • Configuration details (including partitioning), interfaces with other DAQ subsystems (including ETM) This should lead to chapter in DS design document – External Trigger Module : Interfaces with other DAQ subsystems, calibration, beam, • modules, SNEWS This should lead to chapter in DS design document – Data Selection Chain for PDS and define validation and demonstration tests • This should lead to chapter in DS design document – With PP group: finalize metrics for comparing implementations and algorithm • performance and define validation and demonstration tests (for both data selection and data reduction) This should lead to chapter in DS design document – With back-end DAQ group: finalize HLF design (GPU/ML filtering?) and define • validation and demonstration tests This should lead to chapter in DS design document – With upstream DAQ group: define data format and range of rates for CPU and fpga • approaches This should lead to chapter in DS design document – 2. Development DS design: With upstream DAQ: start with benchmarking resource availability for DS algorithms, • and any needs for changes to data flow design (for upgradability—are there other upgrade ideas?); define fpga development path 6
Priorities for DAQ Workshop: (1) DS Design 1. Baseline DS design: Module Level Trigger : Trigger logic (algorithm) outline, Trigger prioritization, • Configuration details (including partitioning), interfaces with other DAQ subsystems (including ETM) This should lead to chapter in DS design document – External Trigger Module : Interfaces with other DAQ subsystems, calibration, beam, • modules, SNEWS This should lead to chapter in DS design document – Data Selection Chain for PDS and define validation and demonstration tests • This should lead to chapter in DS design document – With PP group: finalize metrics for comparing implementations and algorithm • DS WG Meeting Jan. 16: Request WG members take ownership performance and define validation and demonstration tests (for both data selection and data reduction) of these topics leading up to/in preparation for workshop This should lead to chapter in DS design document – With back-end DAQ group: finalize HLF design (GPU/ML filtering?) and define • validation and demonstration tests This should lead to chapter in DS design document – With upstream DAQ group: define data format and range of rates for CPU and fpga • approaches This should lead to chapter in DS design document – 2. Development DS design: With upstream DAQ: start with benchmarking resource availability for DS algorithms, • and any needs for changes to data flow design (for upgradability—are there other upgrade ideas?); define fpga development path 7
Priorities for DAQ Workshop: (2) ProtoDUNE/Teststands Extend the existing ProtoDUNE system to include 'simple trigger chain' functions • defined per previous slide Decide on priority of prototyping DS features at ProtoDUNE by April vs. later; – integrate more with PP group and offline performance evaluation. Discuss with DF group how existing MLT (DS) and DFO (DF/BE) should evolve . – Plan prototyping this with DF for ProtoDUNE. Devise a proposal for how ProtoDUNE partitioning should be extended to – include DS components. Extend above to complete list of DS interfaces to other DAQ WGs (CCM in – particular). Report on MiniDAQ developments and organize testing • A bit later (maybe after workshop?) • Review pTemp (i.e. help make it pPermanent), and extend support – Draw schedule, assign responsibilities. 8
Recommend
More recommend
