RCE and FELIX Raw Data Access for ProtoDUNE Discussion Tom Junk, - - PowerPoint PPT Presentation

RCE and FELIX Raw Data Access for ProtoDUNE Discussion

Tom Junk, with input from JJ Russell, Frank Filthaut, and Wes Ketchum Raw Data Access Meeting June 28, 2017

Need to have a separate discussion about Photon Detector, Trigger, and CRT information

Requirements

• Data access methods ("Overlays") should provide access to the

raw data in a ProtoDUNE event to a caller running art

• Uncompressed ADC data
• Channel identifiers
• Timestamp(s)
• Checksums and other header information (trigger?)
• Error conditions detected
• Data access methods for RCE and FELIX should have a

common interface for a subset that meets all requirements.

6/28/17 Tom Junk | Data Access Methods 2

From DocDB 1701

6/28/17 Tom Junk | Data Access Methods 3

September 9, 2016

Beyond Requirements

• We would like the access methods to be efficient for extracting a

sequence of ADC values for one (or more) channels at a time:

• Offline data format in raw::RawDigit is a vector of shorts per

channel.

• Each element of the vector corresponds to a tick (time bin)
• The vectors of different channels need not be contiguous in memory
• We would like the access methods to return multiple

uncompressed ADC values for one or more channels per call.

• It doesn't have to be the whole event, just more than one per call.
• On 35-ton, we extracted ADC values one 12-bit sample at a

time (slow!)

6/28/17 Tom Junk | Data Access Methods 4

Multi-Tick Access

• In 35-ton, the DAQ stored data in millislices, microslices, and
• nanoslices. A nanoslice is 32 channels for one tick.
• Compression works best when subtracting neighboring time

ticks on a single channel.

• The WIB frames arrive with 256 channels for one tick though.
• RCE's and FELIX (or FELIX host computers) must buffer and

transpose the data before compressing it.

• Wish #1: We should not uncompress the same data more than
• nce when reading an event in (not a requirement, just a wish).
• Wish #2: We should minimize the amount of data cached by the
• verlay methods (another wish, but it impacts our ability to run

jobs).

6/28/17 Tom Junk | Data Access Methods 5

Multi-Tick Access

• One possible method we might like, but we are not insisting on:
• User allocates buffer for unpacked data for one channel for the event (possibly calling
• verlay methods to find out how big that is)
• User inputs channel number and pointer to buffer
• Buffer is filled with all ADC values for that channel in the event
• Issues with this:
• One RCE Packet contains 1024 ticks x 128 channels (what does FELIX produce?)
• Need to at least partially unpack 10 packets for a 10000-tick event for one channel.
• Compression means channel data do not start at fixed offsets within each packet.
• Getting the last channel's worth of data may require unpacking all channels in a

packet (see Wish #1)

• Or we could cache the uncompressed packets, or at least the starting offsets (but see

Wish #2).

6/28/17 Tom Junk | Data Access Methods 6

Multi-Tick Access

• Offline needs to store the event data at least once, so the

buffers can accumulate in the caller's memory

• Proposed alternative: Access methods give us as many

channels and ticks as correspond to a packet. Other access methods are possible but not necessarily speedy.

• Methods to tell us what the packet sizes are in channels x ticks

so we know how to access them efficiently.

• Need to input a list of pointers to be passed in where memory

has been pre-allocated to store all channels' results.

• Or – with minimal caching of state, assuming that channels are

accessed in a sequence that optimizes the unpacking (e.g. 1024 ticks at a time, aligned on a packet boundary, fastest access for the next channel in a packet already started on).

6/28/17 Tom Junk | Data Access Methods 7

non-ADC Data

• Error conditions
• Direct access to capture error words and checksums
• Method to summarize error conditions.
• Keep a running tally of error conditions found in the unpacking
• capture errors, checksum mismatches, timestamp mismatches, missing data,

duplicate or extra data. Unexpected channel ID's.

• Clear the error condition accumulator on each new event.
• Channel ID's
• used as a key to access data
• But we need methods to tell us which channel ID's are present
• May be more efficient to report presence of blocks of channels.
• Timestamps

6/28/17 Tom Junk | Data Access Methods 8

Other items

• Random access?
• Not a priority for offline. Online debugging perhaps?
• Channel map applied
• e.g. "Give me all the X-plane wire data"
• Not a priority for offline.
• Channel map for 35t had bugs in it initially – would rather not bake this in.
• Error summary without returning unpacked data
• If you produce this during the packing process then OK, but if you are going

to unpack all the data anyway to unpack the error words, then might as well just have one set of methods to do it all.

• Mean and RMS – nice, but not needed. If we unpack a packet at a

time, maybe less useful. Online monitoring can compute these.

6/28/17 Tom Junk | Data Access Methods 9

Compressed raw::RawDigits

• raw::RawDigits can store compressed data.
• supported: zero-suppressed and Huffman coding, both formats specific to LArSoft's

implementation

• compressed RawDigits packed into the same vector of shorts as uncompressed data.
• more compression schemes can be added as needed
• Users of raw::RawDigits already uncompress one channel at a time if the flag

is set.

• Can save memory at the cost of CPU.
• Only limitation – all the info needed to uncompress one channel's worth of

data for an event should be contained in that channel's data (and not some

• ther channel's data).
• Offline we can re-compress the data. Only relevance here is if accessor

method returns compressed data as an optimization. Each channel has its

• wn compression flag and compression scheme ID so RCE and FELIX

compression need not be the same.

6/28/17 Tom Junk | Data Access Methods 10

"Advanced"

• Subtracting values from neighboring channels
• useful if there is a lot of correlated noise
• JJ says this is "advanced" and I'm not expecting it to happen
• But it could compress data further.

6/28/17 Tom Junk | Data Access Methods 11