WP3.3 in depth - indico.fnal.gov

WP3.3 in depthDiscussion, WBS, interactions

Simon JM PeetersEdinburgh, 2 Dec 2016

Overview

• DUNE overview in DAQ context• Numbers

• DAQ design options (Babak)

• WP3.3 charge (Dave)

• Initial trigger design (Michael)

• Signals and backgrounds• Rates

• WBS discussion

2016.12.02Simon JM Peeters, WP3.3 discussion, Edinburgh 2

LAr design


2560 readout wires / APA150 APA / 10 ktonne (fiducial) detector

1,536,000 readout wires for 40 ktonneReadout @ 2 MHz, 11 bit ADC (tbc?)(~ 4 TB/s)lbne docdb 3833

Readout in slices• dE/dx MIP: 2.1 MeV/cm

(wire spacing 4.7 mm)

Beam, muons and proton decay

• 1.6 mm / s or 2.25 ms drift time (3.6 m, 3 ms lifetime)

• Readout 2.4 drifts / readout or 21 GB

Supernova

• 10 s: 40 TB or 66 GB / APA (minimal)

• 60 s: 230 TB or 400 GB / APA


Giles/Babak

Triggerprimitives

Giles/Babak

Giles/Babak

Giles/Babak

Giles/Babak

WP3.3 charge

• Needs understanding of signals & backgrounds

• Needs understanding of detector features• Noise levels, coherence, sticky bits

• Strong links with WP 3.4 (DAQ architecture) and WP 3.5 (vertical slice test)


DUNE proposal v3

Current thinking for the triggering

• Initial work done by DAQ simulation group (Michael Bair, Sussex)

• Thinking motivated by supernovae signals


Data rates Supernovae


Summary:

• Following our phone conversation on Friday, Nov. 25th 2016, here are just some of my thoughts and ideas about what to do next with respect to trigger development. Some of it is geared specifically towards supernovae triggering but most of it is general enough to apply to any type of triggers.

• Note that these are not all my ideas. This is just a snapshot of how I think the system is shaping up to work...

Michael Baird

A model for triggering:

1. RCEs will run simple hit-finders on collections wires.

2. These individual hits will be the trigger primitives (TPs) which will be made into small data packets (not bigger than 4 floats –probably smaller) and passed on to the trigger computer(s).

APADAQ Trigger Farm

packet of TPs (one per wire hit)

Each TP (could) contain:• pulse height• duration• hardware address• time stamp

...

RCE



Michael Baird

A model for triggering (2):

• Within the trigger computer(s), TPs will be collected from all hardware over time.

• A “sliding-window” trigger algorithm will monitor the list of TPs within a fixed interval of time to make a trigger decision.

• Trigger decisions could be simple (counting the number of TPs in the detector) or more complex (applying some time/space clustering based on hardware addresses.)

• A trigger decision (with a trigger “word” indicating the trigger type) will be sent back to the RCEs telling them to save their data, which data to save, and which trigger stream to send the info to.

• For a supernova, one could imagine an additional layer that counted the number of “low energy” triggers issued over a longer period (maybe something like 100 ms.)

T.P.

time

T.P.

T.P.

T.P.

T.P.

T.P.

T.P.

T.P.

Michael Baird

This is just an outline of the next steps as I see them. Things (obviously) don’t have to be done in this order...

Modeling the trigger system:

• implement a simple hit-finding algorithm within my trigger framework to generate trigger primitives

• program these algorithms into the FPGAs on a real COB to test the performance

• try out some simple clustering algorithms that take the trigger primitives as input (could easily be modeled within my trigger framework)

• generate requirements for the DAQ – data/network rates, trigger farm requirements, algorithm speeds, etc.

Modeling Supernova Triggers:

• use the above to generate input histograms for the supernova time-profile simulator

• use the TP-simulator to make statements (detection efficiency, false trigger rate, etc.) about different trigger algorithms, running under different conditions (levels of noise / backgrounds)

Thoughts on the “next steps”

Michael Baird

References:

Here are just some other talks I given as reference:

Summary of data rates, supernova triggering, and my toy SNe time-profile simulator:https://indico.fnal.gov/getFile.py/access?contribId=164&sessionId=16&resId=0&materialId=slides&confId=10613

A wiki for my trigger framework:https://cdcvs.fnal.gov/redmine/projects/dunetpc/wiki/Using_the_DAQTriggerSim_module

Michael Baird

Signals and backgroundsSignals

• Beam spillsreadout everything for one spill

• Muons• Atmospheric neutrinos

(01.-100 GeV)120 / ktonne / yr

• Solar neutrinos (5-15 MeV1300 / ktonne / yr

• Happen once events• Proton decay (100s MeV)• Supernovae (10-50 MeV)

Backgrounds

• 39Ar 0.5 MeV endpointsingle wire1 Bq/kg or 60 kHz / APA

• Low energy backgrounds (222/220Rn)up to 3 MeV 1 – 3 wires

• Noise


Data rates


Data rate trigger objects:4 bytes / object and ~60 kHz LAr / APA: 240 kB/sat a 100% trigger efficiency

M. Baird

WBS – crude starting pointA) INPUT: Gather / simulate inputs

1. 39Ar and low-energy backgrounds2. Noise models (incl coherent noise, sticky bits)

3. Beam spill data

4. Muon data5. Supernovae data

6. Proton decay

B) PROCESS: Vertical slice test1. Convert A to input

2. Implement processes:noise suppression, compression, trigger primitive generation

3. Evaluate performance for A1-6

C) TRIGGER FARM: simulate1. Trigger primitives (based on A&B) as input,

evaluate performance and physics reach

D) Test in ProtoDUNE1. Tension against A: Determine realistic scenarios

2. Test solutions (Michel electrons for SN?)


Gain understanding of data with backgrounds, data rates in different scenarios

Evaluate options in differentimplementations

Physics performance

Technology evaluation

Documents

WP3.3 in depth - indico.fnal.gov