Could the TC Fragment be stored in the latency buffer based on the trigger time?

[bieryAtFnal]

(This is a topic for post-v3.0.0, and it relates to long-window-readout [when the readout of the data for a trigger is split into a sequence of TriggerRecords].
The title of this Issue makes an assumption about how TC fragments are handled within the Trigger App. If that assumption turns out to be wrong, I will correct the title. The text below describes what is desired without going into details of how things might work under the covers.)

Currently, when we run with long readout windows and split the data into a sequence of TriggerRecords, the TC Fragment has meaningful contents for only one of the N TriggerRecord in the sequence of TRs. The TC fragment is empty for the other N-1 TRs in the sequence. (This has been discussed elsewhere.) And at the moment, the non-empty TC Fragment appears in the first TR of the sequence.

Could the non-empty TC Fragment instead appear in the TriggerRecord that spans the trigger time? That might better match what users expect...

[philiprodrigues]

To check I understand correctly, you're thinking of this situation:

• Trigger timestamp 1500
• TriggerRecord00001.0000 contains times [0, 1000]
• TriggerRecord00001.0001 contains times [1001, 2000]
• TriggerRecord00001.0002 contains times [2001, 3000]

Then you'd want the TC to be included in TriggerRecord00001.0001? That's probably doable for a single TC per TD. I'll have to think a bit about what happens (in the future) when there are potentially multiple TCs per TD

[bieryAtFnal]

Yes, that description exactly matches what I'm requesting, that the non-empty TC Fragment be included in TriggerRecord00001.0001.

As we mentioned in other discussions, it's likely/expected that we'd see empty TC Fragments in TriggerRecord00001.0000 and TriggerRecord00001.0002...

[CharlieBatchelor]

Hi @bieryAtFnal - Is this splitting still observed in the long readout window tests? The splitting is a feature of the TRBs, where the splitting by default should not occur according to the current daqconf schema, via this line .

[bieryAtFnal]

Hi Charlie, yes, the splitting of long-readout-window TriggerRecords into multiple sequence elements is still something that we are interested in. I know that Wes runs tests with that type of configuration at EHN1 at various times, and that type of configuration is part of one of our automated integration tests.
If, however, the functionality that this Issue requests would be hard to implement, we could talk about dropping the request (and educating everyone about the behavior that is implemented).
Thanks

[ArturSztuc]

I'm going to repeat Charlie and ask, @bieryAtFnal is this still observed?
I remember very long readout windows (that span multiple TRs) were used in e.g. the initial laser system tests on np04, was it still the case that the TC was only present in the very first TR but not the rest?

And the desired behaviour would be to have that TC be present in every TR that overlaps with the TC's time-window?

[bieryAtFnal]

@ArturSztuc,

Yes, this is still happening. The TC fragment is only non-empty for the first element in the sequence of TriggerRecords.

I'm not sure what the desired behavior should be. My original request asked that it be present just once, but at a different position in the sequence. But maybe what we have now is what we want...