35t Joint Meeting 20141020

This meeting was called to have a discussion to help disseminate understanding of issues that pertain to online/offline interface w.r.t. the 35t detector. It was driven by some questions (some naive) that were distributed before.

Misc Questions

In no particular order, these are the questions pertaining to DAQ and its interface with off-line:

• what is the low level DAQ file format/encoding (ROOT? binary?)
• what schema does the content of DAQ files follow?
• where is a diagram showing all the parts of the DAQ data stream with their names (millislice, microblock, tick, "trigger", etc)?
• what is the start/stop criteria that defines the highest level "chunk" of data (e.g. a "trigger")?
• how does this "chunk" correspond to a trigger for each expected trigger criteria?
• what time-ordering is expected from data coming out of the DAQ, particularly between disparate sources (e.g. Wires/PDs)?
• are we going to implement a "world clock" with 1 us resolution?
• what unit of data "chunk" ("event") is required and desired for offline analysis?
• what offline analysis decisions/limitations can we, as a collaboration, be comfortable "baking in" to this choice of unit?
• how are DAQ data "chunks" (triggers) numbered? How are offline data "chunks" ("events") numbered?
• what is the mapping from the former to the latter?
• what changes to art and/or LArSoft are needed to accommodate the above answers?

Notes

BV

These notes were taken by BrettViren.

In overview, we started out following the list of questions but then branched out into more free form (and fruitful) discussion. The notes are a set of bullet points I scribbled down as we went and may not be fully coherent.

• Low-level file format will be a ROOT file containing ROOT TTree objects
• The schema of these objects will be a collection of binary data "blobs"
• C++ "overlay" classes are being developed which will handle the unpacking.
• The are in a library that depends on Art but otherwise independent of online and offline
  • (followup to check: is it reasonable to make this library independent from Art?)
• An ArtDaq raw "DaqEvent" is a vector of ArtDaq "fragments", a fragment is a "blob" of data with some meta data, "blob" means experiment-defined packed data
• A fragment translates into 35t names as a millislice
• See DocDB #9677 for list of run modes from Giles
• See DocDB #9871 for issues pertaining to 35t raw object definitions from Jeff
• Blobs follow internal schema and have a version to indicate this
• We should put both this version and a timestamp in a location that is version-independent
• Q: (from Josh) Why is there a microslice? A: (from Giles) this assures all data streams are kept in lock-step
• Q: Why is there a milislice? A: see Jeff's slide #7
• A "trigger" is applied in ArtDaq. A better description would be to call this a "filter". Exactly one "trigger" or "filter" condition is in effect for an entire "run"
• Run mode 1&2 assume zero-suppression
• milliblock stores absolute timestamps. These are from 56 bit, 64MHz clock from the Nova time system