art building events out of DTC fragments with different event tags

[pavel1murat]

printout of one of the problematic events (120434:1:4737) is attached below.
The event contains 4 DTC fragments in total, 3 fragments have the same event window tag,
the fourth fragment has a event window tag different by two.

run_120434_even_4737.txt

[eflumerf]

artdaq builds events by Fragment Sequence ID. Can you do an art -c verboseRawEventDump.fcl on one of these files and see which Fragment has a mismatched timestamp? Mu2e Fragment Generators generally set the Sequence ID and timestamp fields the same, and get that information from the EWT in the data stream. One place that a difference can occur is in the request handling; artdaq will create a ContainerFragment with a Sequence ID matching the request ID number (but the contained Fragments should retain their original Sequence IDs).

[pavel1murat]

1. the data file in question can be found in the mu2e-dl-01:/data/mu2e/mu2etrk/daquser_002_v001/data area.
2. the work area is mu2e-dl-01:/home/mu2etrk/daquser_002

[pavel1murat]

to add :

• artdaq run_records area: /scratch/mu2e/mu2etrk/daquser_002_v001/run_records
• an example of an artdaq event built out of fragments with three different timestamps attached
• this is observed in a configuration with two event builders

run_120438_ev_520002_corruption.txt

[eflumerf]

The problem appears to be on line 591 of TrackerBRDR_generator.cc, where you allow the timestamp to be different than the sequence ID in the generated Fragment. This is MIDAS user code, and not relevant for the official data-taking channels.

It would help for you to set the Fragment IDs appropriately for each BoardReader so you could tell which one was getting offset. This was probably caused by data loss in the MIDAS->artdaq transition.

[pavel1murat]

for Mu2e, 'uniqueness' of an event is defined by its event window tag, and not by anything else. So is it a statement that the fragment sequence ID should be the same as the event window tag ?