ProtoDUNE DP data Vyacheslav Galymov, IPN Lyon On behalf of D. - PowerPoint PPT Presentation

Raw decoder for ProtoDUNE – DP data Vyacheslav Galymov, IPN Lyon On behalf of D. Autiero, E. Bechetoille, F. Berthet, D. Caiulo, B. Carlus, Q. David, F. Doizon, C. Girerd, T. Hasegawa, H. Mathez, E. Pennacchio, D. Pugnere, K. Sakashita, W. Tromeur

Overview • Various conventions for ProtoDUNE – DP readout • Signal feedthrough / uTCA crate ordering • CRP cabling  channel map convention • Overview of the data flow  format of the written raw data • Unpacking NP02 raw data within dunetpc 2

The uTCA DAQ architecture of ProtoDUNE-DP integrated with White Rabbit (WR) Time and Trigger distribution network. White Rabbit slaves MCH nodes in uTCA crates + WR system (time source, Grand Master, trigger system) Online LV1 events builders 7 + Storage and 6 10Gbe links processing Farm 40 Gbe backbone WR 20 GB/s Trigger disk bandwidth LV2 events Server builders 3

Warm flange interface to analog FE cards located in dedicated signal feedthroughs DP TPC Electronics digital front-end CRO AMCs WR MCH MCH WR timing/trigger packets PU 1 Gbit/s SyncE 10 Gbit/s data link 4

SGFT1 Example BEAM Cryogenics CRP2 V 3 2 H 1 H 1 H 2 KEL connectors Slot 1: H1_1, H1_2 CRP2 numbering Slot 2: H1_3, H1_4 CRP2 1 5 1 5 Slot 3: H1_5, H2_1 CRP2 Slot 1 Slot 4: H2_2, H2_3 CRP2 1 Slot 5: H2_4, H2_5 CRP2 Slot 10 Slots 6-10 empty 5

CRP & SGFT numbering conventions Entrance DOOR CRP1 BEAM 7 Cryogenics CRP2 8 HV FT V 9 6 4 5 2 3 H 1 10 10 Chimney 1: 5 cards H1(one row of anodes),H2 CRP2 Chimney 2: 5 cards H3,H4 CRP2 1 10 CRP4 1x1 m 2 Chimney 3: 5 cards H5,H6 CRP2 (anodes 2x2) 11 11 Chimney 4: 10 cards H1,H2 CRP1, H1,H2 CRP4 (anodes) Chimney 5 5 cards H3,H4 CRP1 Chimney 6 5 cards H5,H6 CRP1 Chimney 7 10 cards V5,V6 CRP1, V5,V6 CRP2 12 12 Chimney 8 10 cards V3,V4 CRP1, V3,V4 CRP2 Chimney 9 10 cards V1,V2 CRP1, V1 ,V2 CRP2 Chimney 10 5 cards V5,V6 CRP4 (anodes) Chimney 11 empty Chimney 12 empty 6

Data flow See this for more details 7

Data format: fragments from L1evb Each L1 event builder generates an event fragment written to a common memory location with the L2 event builders The format of the fragment: Fragment header (44b) + data bytes (CRO data size + LRO data size obtained from fragment header) Fragment header format #1-2 FFFF (2 bytes) Trigger event info from #3-6 RUN NB (4 bytes) White Rabbit system #7 FLAGS (1 byte) indicates protoDUNE setup and compression #8-31 TRIGGER INFOS (24 bytes) #32 DATA QUALITY FLAG #33-36 EVENT NUM (4 bytes) Indicates id of one of the TTL inputs #37-40 LRO DATA SIZE:0 (4 bytes) #41-44 CRO DATA SIZE (4 bytes) 8

Data format: files from L2evb Four L2 merge two L1 fragments into a single record:  Event == Fragment L1evb A + Fragment L1 evb B For four L2 each the event distribution for the processes is a follows: Once each L2 accumulates a given number of events (defined via Run control) in memory, the file is written out The written file contains an “event table” at the beginning that indicates the number of events in the file and size of each event in bytes  so one can access any event by moving fstream to a given position 9

Charge Readout Raw Data The order the channel data are stored in each fragment is fixed: Crate 1: AMC 1: Ch 1 … 64 Each record can be assigned a sequence index ID AMC 2: “channel number” from 0 … 7679 (there are 7680 Ch 1 … 64 channels in total): … Then data are unpacked into a vector of AMC 10: Ch 1 … 64 raw::RawDigit s one has to remap this Crate 2: sequence index to CRP / view channel AMC 1: numbering Ch 1 … 64 AMC 2: CRP 1 & 2 have 2 views with 960 channel each, Ch 1 … 64 while CRP 4 has only has 320 channels per each … view Etc. 10

Coordinate system definition for mapping to views X Entrance DOOR CRP1 BEAM V 7 Cryogenics H CRP2 8 HV FT 9 6 4 5 2 3 1 Origin Z 10 10 Y – is UP  e drift along +Y 10 1 CRP4 (anodes 2x2) 11 11 Z is along +H axis (View 0) X is along +V axis (View 1) 12 12 Origin is middle of TPC defined on the 6x6x6 cube side close to the cryo platform 11

Defining channel map The map is set up with the help of boost::multi_index container, which supports unique / non-unique / hashed keys and indexing on several parameters All possible indexes are encapsulated within a single class Defines unique key given by the order in which channels are stored in file These triplets give unique key Indicates if this is a valid data channel: the data size is fixed to 12 crates, while in current 2 CRP configuration only have are active Example: defining ordered and hashed index of the container for sequence number 12

Channel mapping Can retrieve info from the channel map in different ways: • By seq number of unpacked channel data • By crate id / AMC card id / AMC channel no • By CRP id / view id / view ch no  Can recover data ptr / iterator for any given channel representation from the unpacked ADC raw data buffer in a common memory location 13

Map channel table index definition // boost multi index container typedef multi_index_container< ChannelId, indexed_by< ordered_unique< tag<IndexRawSeqn>, const_mem_fun< ChannelId, const unsigned, &ChannelId::seqn > >, hashed_unique< tag<IndexRawSeqnHash>, const_mem_fun< ChannelId, const unsigned, &ChannelId::seqn > >, hashed_non_unique< tag<IndexCrate>, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crate > >, hashed_non_unique< tag<IndexCrateCard>, composite_key< ChannelId, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crate >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::card > > >, ordered_unique< tag<IndexCrateCardChan>, composite_key< ChannelId, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crate >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::card >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::cardch > > >, hashed_unique< tag<IndexCrateCardChanHash>, composite_key< ChannelId, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crate >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::card >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::cardch > > >, hashed_non_unique< tag<IndexCrp>, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crp > >, hashed_non_unique< tag<IndexCrpView>, composite_key< ChannelId, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crp >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::view > > >, ordered_unique< tag<IndexCrpViewChan>, composite_key< ChannelId, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crp >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::view >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::viewch > > >, hashed_unique< tag<IndexCrpViewChanHash>, composite_key< ChannelId, const_mem_fun< ChannelId, const unsigned short, &ChannelId::crp >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::view >, const_mem_fun< ChannelId, const unsigned short, &ChannelId::viewch > > > > > ChannelTable; // // Basically define a container indexing based on different attributes of a class 14

Channel map application example: NP02 event display Developed in Qt4 using Qwt library for plotting Can examine an event in different representations (useful for debugging) 15

ProtoDUNE DP raw data decoder in dunetpc In /dunetpc/dune/Protodune/dualphase/RawDecoding Define a custom ART input source in PDDPRawInput_source.cc In fcl declare: Relevant code is contained in PDDPRawInputDriver: • Opens the binary files generated by NP02 DAQ and unpacks events • The raw ADC data (compressed/uncompressed*) are stored in raw::RawDigit vector that will have to be mapped to other representations, e.g., CRP / view, for reconstruction purposes *currently the data are not compressed 16

To Do list • Complete interface to the raw data: • Add RDTimeStamp (same as event WR timestamp) and RDStatus (build it from DQ event flags) information • Add the channel mapping • Exercising the machinery (global effort): • Test DataPrepModule stage: recob::wire ROIs • Higher reconstruction (hit  2d tracks  3d tracks ) • Compatibility of the geometry for PDDP with 2 CRPs configuration to be tested 17