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

protodune dp data
SMART_READER_LITE
LIVE PREVIEW

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.


slide-1
SLIDE 1

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
slide-2
SLIDE 2

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

slide-3
SLIDE 3

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)

WR Trigger Server LV1 events builders 7 + 6 10Gbe links LV2 events builders

Online Storage and processing Farm 20 GB/s disk bandwidth

40 Gbe backbone 3

slide-4
SLIDE 4

DP TPC Electronics digital front-end

4

WR MCH MCH CRO AMCs WR timing/trigger packets 1 Gbit/s SyncE 10 Gbit/s data link PU Warm flange interface to analog FE cards located in dedicated signal feedthroughs

slide-5
SLIDE 5

Cryogenics BEAM CRP2 1 2 3 H V 1

1

H 1 H 2

5 5 1

Slot 1: H1_1, H1_2 CRP2 Slot 2: H1_3, H1_4 CRP2 Slot 3: H1_5, H2_1 CRP2 Slot 4: H2_2, H2_3 CRP2 Slot 5: H2_4, H2_5 CRP2 Slots 6-10 empty Slot 1 Slot 10

KEL connectors numbering

SGFT1 Example

5

slide-6
SLIDE 6

Cryogenics Entrance DOOR HV FT 1 10 BEAM CRP1 CRP2 CRP4 1x1 m2 (anodes 2x2) 1 2 3 4 5 6 7 8 9 10 10 11 11 12 12 Chimney 1: 5 cards H1(one row of anodes),H2 CRP2 Chimney 2: 5 cards H3,H4 CRP2

Chimney 3: 5 cards H5,H6 CRP2 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 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

H V

CRP & SGFT numbering conventions

6

slide-7
SLIDE 7

Data flow

See this for more details

7

slide-8
SLIDE 8

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)

#1-2 FFFF (2 bytes) #3-6 RUN NB (4 bytes) #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) #37-40 LRO DATA SIZE:0 (4 bytes) #41-44 CRO DATA SIZE (4 bytes)

Fragment header format Trigger event info from White Rabbit system Indicates id of one of the TTL inputs

8

slide-9
SLIDE 9

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

slide-10
SLIDE 10

Charge Readout Raw Data

The order the channel data are stored in each fragment is fixed:

Crate 1: AMC 1: Ch 1 … 64 AMC 2: Ch 1 … 64 … AMC 10: Ch 1 … 64 Crate 2: AMC 1: Ch 1 … 64 AMC 2: Ch 1 … 64 … Etc.

Each record can be assigned a sequence index ID “channel number” from 0 … 7679 (there are 7680 channels in total): Then data are unpacked into a vector of raw::RawDigits one has to remap this sequence index to CRP / view channel numbering CRP 1 & 2 have 2 views with 960 channel each, while CRP 4 has only has 320 channels per each view

10

slide-11
SLIDE 11

Coordinate system definition for mapping to views

Y – is UP  e drift along +Y Z is along +H axis (View 0) X is along +V axis (View 1) Origin is middle of TPC defined on the 6x6x6 cube side close to the cryo platform

Cryogenics Entrance DOOR HV FT 1 10 BEAM CRP1 CRP2 CRP4 (anodes 2x2) 1 2 3 4 5 6 7 8 9 10 10 11 11 12 12 H V

X Z Origin

11

slide-12
SLIDE 12

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 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

  • nly have are active

All possible indexes are encapsulated within a single class Example: defining ordered and hashed index of the container for sequence number

12

slide-13
SLIDE 13

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

13

 Can recover data ptr / iterator for any given channel representation from the unpacked ADC raw data buffer in a common memory location

slide-14
SLIDE 14

Map channel table index definition

14

// boost multi index container typedef multi_index_container< ChannelId, indexed_by<

  • rdered_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 > > >,

  • rdered_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 > > >,

  • rdered_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

slide-15
SLIDE 15

Channel map application example: NP02 event display

Can examine an event in different representations (useful for debugging)

15

Developed in Qt4 using Qwt library for plotting

slide-16
SLIDE 16

ProtoDUNE DP raw data decoder in dunetpc

In /dunetpc/dune/Protodune/dualphase/RawDecoding Define a custom ART input source in PDDPRawInput_source.cc

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

In fcl declare:

16

slide-17
SLIDE 17

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