DFO Ideas for May/June - INDICO-FNAL (Indico)...Assignment Adding a few message details 5...

DFO Ideas for May/JuneKurt Biery, Wes KetchumDUNE DAQ Meeting01 April 2019

IntroductionGiovanna asked about possible progress in prototyping the DUNE DAQ DFO for the May/June DAQ testing weeks at protoDUNE…The short answer is ‘Yes, this can be done’, and this talk will present some of the ideas for steps that can be taken.

01-Apr-2019 KAB & WRK, DFO ideas for May2


Starting from the last diagram in Giovanna’s presentation at the 22-Mar-2019 Data Selection meeting…• One note is that the RoutingMaster is gone in this diagram• During Giovanna’s talk, we agreed that the lines between the EBs and the BRs are

bi-directional (data requests sent upstream, data fragments sent downstream)• The presence/absence of the Trig Cand. boxes is not important for this talk

Attempting to focus on just part of the previous diagram


SW Trigger

DFOEvent Builders

CTB, FELIX, FELIX HF, and SSP BRs

Trigger Info

TriggerAssignment

Adding a few message details


SW Trigger

DFOEvent Builders


Trigger Info

TriggerAssignment

(To EB: Trigger Command;From EB: Availability)

To BRs: Data Request;From BRs: Data Fragments

On the cusp of DFO details


SW Trigger

The DFO blob

Event Builders


Trigger Info

TriggerAssignment



DFO blob details – possible future view


SW Trigger

The DFO blob

Event Builders


Trigger Info

TriggerAssignment



[Someday]DFO process

DFO blob details – current thought


SW Trigger

The DFO blob

Event Builders


Trigger Info

TriggerAssignment



[May/June]N collaborating

processes

DFO blob details – design question


SW Trigger

The DFO blob

Event Builders


Trigger Info

TriggerAssignment



Would it be OK to transfer the SWTrigdata payload through the DFO blob,at least for these initial tests?As before, it will still be included inthe raw event, it would just follow adifferent path than suggested recently.

X


processes

DFO blob details – SWTrig data thru the DFO


SW Trigger

The DFO blob

Event Builders


Trigger Info

Trigger Assignment(To EB: Trigger Command & SWTrig Data;From EB: Availability)



processes

Short digressionI’ve probably not always been clear in explaining one of the core concepts in artdaq…

This is the concept of having an entity that…• receives data, packages it appropriately, hands it over to an analysis

process, and optionally sends it along to another DAQ entity

[This pattern is used for EventBuilders, DataLoggers, and Dispatchers in the current system. And, it also can be used for other things.]

Our proposal is to use this pattern for the DFO.• The ’analysis’ part of the DFO function is fairly straightforward –

matching triggers with available EventBuilders – but maybe there will be other ideas that come up, so it will be nice to have it available.

• There are system configuration options in the existing artdaq system that allow the addition of a DFO entity to be set up easily (more later).


DFO blob details – proposed goal for May/June


SW Trigger

The DFO blob

Event Builders


Trigger Info

EB Availability


pDFO,(nee EB)

artTrigger Command & SWTrig Data

May/June goal – proposed message details


SW Trigger

The DFO blob

Event Builders


Trigger Info (artdaq::Fragment)

EB Availability(existing msg)

To BRs: Data Request (DESTINATION ADDED);From BRs: Data Fragments

pDFO

artTrigger Command & SWTrig Data

(artdaq::Fragment)

Changes needed to achieve this goalThe Data Request needs to have destination information added to it. BoardReader internals need to use the destination from the Data Request rather than the routing table when sending Data Fragments.We’ll need to copy the functionality that handles the receipt of EventBuilder Availability tokens and decides where to route the next event into the DFO art process.


Quick aside on namingAs I mentioned, the proposal is to use an EventBuilder process as the initial prototype DFO. This is a convenience, and this can easily be reframed as using the standard artdaq pattern of “data receiver&packager plus analysis” entity to meet the need of another DAQ function.

Similarly, I would hope that people understand that an artdaq::Fragment is just a way to communicate between processes. It’s basically just a container. The important part is the payload within that container.


1st small step – already working in a demo system


SW Trigger

The DFO blob

Event Builders



EB Availability


pDFO

art RoutingMaster

Trigger Command& SWTrig Data

(artdaq::Fragment)

Routing Tables

2nd step – add destination to Data Request, change the BR to use this destination


SW Trigger

The DFO blob

Event Builders



EB Availability

To BRs: Data Request (DESTINATION ADDED);From BRs: Data Fragments

pDFO

art Routing Master


(artdaq::Fragment)

Routing Tables

3rd step – move RM pieces into DFO art process


SW Trigger

The DFO blob

Event Builders



EB Availability

To BRs: Data Request (DESTINATION ADDED;From BRs: Data Fragments

pDFO

art


(artdaq::Fragment)

Features covered in steps 1-3Suggested features from Giovanna:ü event assignment sent to relevant EB (and elimination of

routing master app) when DFO receives a triggerü all BRs transformed to be in pull mode ü fragment request from EBs containing destination ü EB informing DFO of available credits (or end of event)


Additional featuresFrom Giovanna:• DFO generating inhibits if no credits are available

- 4th step (KAB: mandatory)• the data request should be made accessible from the core of the BR

to the Fragment Generator, so we could get rid of the extra zeromqmessages from the SWTrig that tell BRs to compress desired time windows

- 5th step (KAB: desirable; amount of work TBD)• add the readout time window to the Trigger Command and Data

Request messages

- 6th step (KAB: stretch goal)


DFO Ideas for May/June - INDICO-FNAL (Indico)...Assignment Adding a few message details 5...

Documents

Transcript of DFO Ideas for May/June - INDICO-FNAL (Indico)...Assignment Adding a few message details 5...