Iss1053 -- add "no spacing" capability to MC readout

[bloodyyugo]

We want to be able to read out the MC+pulser overlay event without putting a lot empty bunches between the events so that the readout system can handle it without piling up all the hits in time.

The hack I did was:

-- in ReadoutDataManager, which carries the global time, each event gets incremented by 250 bunches (500ns) instead of the single bunch-per-event in the spaced MC
-- for the sim readout, digitization, GTP cluster making and triggering, I created a bunch of "NoSpacing" classes mostly copied from/named similarly to their corresponding classes used for the spaced MC. I changed the timing of where the digitized pulses were placed to make them all be around the time given in readoutTime, removing some latencies.
-------------- I may revisit this now that I understand the procedure better. We may just be able to adjust the numbers (and maybe a little code) to get this to work with existing code.

This is not ready for primetime yet.

[bloodyyugo]

Took a couple different turns here but settled on just:

1. add settable boolean doNoSpacing to ReadoutDriver.java (all drivers inherit from)
2. add settable int effectiveBunches to ReadoutDataManager.java; this sets time increment/even to effectiveBunches*2ns....set to 1 for spaced readout, 250 for unspaced
3. small modifications to readout drivers to work with the unspaced readout; in particular, instead of using any "internal" clocks, they just get the global time from ReadoutDataManager

[bloodyyugo]

To test this, I ran over an unspaced tritrig file: /fs/ddn/sdf/group/hps/mc/tritrig/slic/3pt74/20um120nA/HPS_Run2021Pass1_v4newBot/tritrig_3pt74_20um120nA_rot_863.slcio

...and the corresponding spaced file (both provided by SarahG):
/fs/ddn/sdf/group/hps/users/sgaiser/mc/spaced_only_out/tritrig_spaced_3pt74_HPS_Run2021Pass1_v4newBot_863.slcio

I ran 3 versions of readout, with noise turned off so I could compare on equal footing, and found this many triggers:
new unspaced readout (doNoSpacing = true): 922 triggers
new spaced readout (doNoSpacing = false): 883
current master spaced readout: 883
..so, the old spaced readout (current master) and the new code (supposed to just add no spacing functionality) show the same triggers. That is good!

We find ~5% more triggers with the unspaced readout. Digging through lots of print statements in the spaced/unspaced readout, these are mostly (all? all that I checked) have the ecal gtp cluster that would trigger a 4ns tick earlier than the trigger gets the hodoscope patterns. If there is not both a gtp cluster and a hodoscope pattern in the same 4ns tick, the code returns without triggering. The hodo patterns are actually available to the trigger for an extended period (many 4ns ticks) but the gtp clusters only a single one.

I think it's weird that the trigger requires both the hodo pattern and gtp cluster collections exist at the same time period, since I'm pretty sure one of singles2 or singles3 doesn't require the hodoscope. Is this really reproducing what the real trigger does?

[tongtongcao]

To test this, I ran over an unspaced tritrig file: /fs/ddn/sdf/group/hps/mc/tritrig/slic/3pt74/20um120nA/HPS_Run2021Pass1_v4newBot/tritrig_3pt74_20um120nA_rot_863.slcio

...and the corresponding spaced file (both provided by SarahG): /fs/ddn/sdf/group/hps/users/sgaiser/mc/spaced_only_out/tritrig_spaced_3pt74_HPS_Run2021Pass1_v4newBot_863.slcio

I ran 3 versions of readout, with noise turned off so I could compare on equal footing, and found this many triggers: new unspaced readout (doNoSpacing = true): 922 triggers new spaced readout (doNoSpacing = false): 883 current master spaced readout: 883 ..so, the old spaced readout (current master) and the new code (supposed to just add no spacing functionality) show the same triggers. That is good!

We find ~5% more triggers with the unspaced readout. Digging through lots of print statements in the spaced/unspaced readout, these are mostly (all? all that I checked) have the ecal gtp cluster that would trigger a 4ns tick earlier than the trigger gets the hodoscope patterns. If there is not both a gtp cluster and a hodoscope pattern in the same 4ns tick, the code returns without triggering. The hodo patterns are actually available to the trigger for an extended period (many 4ns ticks) but the gtp clusters only a single one.

I think it's weird that the trigger requires both the hodo pattern and gtp cluster collections exist at the same time period, since I'm pretty sure one of singles2 or singles3 doesn't require the hodoscope. Is this really reproducing what the real trigger does?

[tongtongcao]

For each clock cycle, all hodoscope hits in a range of time (before and after the clock cycle) are collected to build hodoscope patterns. Slides 8&9 in the attached file explain how the hodoscope pattern driver works.
Updates of the Readout System for 2019 MC.pdf

[bloodyyugo]

Yeah, I understand this. All I am saying is that, for those ~5% of inserted MC signal events, the time of the gtp cluster that would make a good trigger is before that hodoscope pattern time window and thus doesn't actually make a trigger. And the unspaced readout, with simpler time structure counts there as good triggers so unspaced may overestimate overall efficiency (and thus rates) by this ~5%.

However, I want to make sure that this is in line with what we expect for real triggers?
Do we expect to miss 5% of good triggers because the positron cluster ends up in a time bucket that's too early compared to the hodo?
And, don't we have a trigger that does not depend on the hodoscopes, just the ecal?

For each clock cycle, all hodoscope hits in a range of time (before and after the clock cycle) are collected to build hodoscope patterns. Slides 8&9 in the attached file explain how the hodoscope pattern driver works. Updates of the Readout System for 2019 MC.pdf

[tongtongcao]

One question: for those extra 5% triggers, could you check if GTP cluster and hodoscope pattern with 4ns shift come from the same signal, or by accident, one is from signal, while the other is from background, or even both of them are from background.
Another question: Is count of triggers for single3 or for single2&single3? In other words, is the steering file you used for multiple single triggers, or only for single3? As I remember (need to double check), single2 doe not require mapping between GTP and hodoscope, it means that even if no hodoscope matching with GTP, trigger will not missed since single2 trigger is still sent out.

[tongtongcao]

You claimed that "the ecal gtp cluster that would trigger a 4ns tick earlier than the trigger gets the hodoscope patterns."
According to current setup for hodoscope, persistentTime = 60 ns, timeEarlierThanEcal = 0. It means that at a time clock (t), hodoscope hits between [t -60, t+4] will be collected to build hodo patterns.
https://github.com/JeffersonLab/hps-java/blob/master/ecal-readout-sim/src/main/java/org/hps/readout/hodoscope/HodoscopePatternReadoutDriver.java#L156-L164
How could be GTP cluster earlier than hodo patterns, where hodo hits persist 60ns?

[bloodyyugo]

I am running both singles2 and singles3 triggers. I'm running this steering file (which I think is standard):

https://github.com/JeffersonLab/hps-java/blob/master/steering-files/src/main/resources/org/hps/steering/readout/PhysicsRun2019TrigSinglesWithPulserDataMerging.lcsim

It seems like the code on line 151 of the singles readout driver requires both pattern and gtp clusters be present for the trigger decision to be made:

https://github.com/JeffersonLab/hps-java/blob/054ee5d43d5e36618d248d41a6b8c124d2be3304/ecal-readout-sim/src/main/java/org/hps/readout/trigger2019/SinglesTrigger2019ReadoutDriver.java#L145C9-L155C27

So, even if it's looking for a singles2 trigger (no hodo in decision) the code does require that a pattern is present. As I mentioned in an above comment, this seems incorrect.

One question: for those extra 5% triggers, could you check if GTP cluster and hodoscope pattern with 4ns shift come from the same signal, or by accident, one is from signal, while the other is from background, or even both of them are from background. Another question: Is count of triggers for single3 or for single2&single3? In other words, is the steering file you used for multiple single triggers, or only for single3? As I remember (need to double check), single2 doe not require mapping between GTP and hodoscope, it means that even if no hodoscope matching with GTP, trigger will not missed since single2 trigger is still sent out.

[tongtongcao]

Ah... I got where the issue took place:
https://github.com/JeffersonLab/hps-java/blob/054ee5d43d5e36618d248d41a6b8c124d2be3304/ecal-readout-sim/src/main/java/org/hps/readout/trigger2019/SinglesTrigger2019ReadoutDriver.java#L145C9-L155C27
It requires that size for both GTP clusters and hodo patterns are not 0 for any single trigger. Codes here are only for single3 trigger (we only needed events with single3 trigger before).
I missed to modify these codes when updating readout system to processing multiple triggers.
The bug causes issue when we process both single2 and single3 triggers, as you found.
The bug also significantly affects 2021 Moller MC since 2021 Moller MC readout uses this driver with single1 trigger.
Thanks for the nice finding. I will fix the bug with a PR soon.

[bloodyyugo]

I think this is ready for others to test. I've added a steering file here:

https://github.com/JeffersonLab/hps-java/blob/iss1053/steering-files/src/main/resources/org/hps/steering/readout/PhysicsRun2019TrigSinglesWithPulserDataMergingNoSpacing.lcsim

[bloodyyugo]

I've also added a recon file with the correct SVT hit timing offset here:

https://github.com/JeffersonLab/hps-java/blob/iss1053/steering-files/src/main/resources/org/hps/steering/recon/PhysicsRun2019MCRecon_KF_NoSpacing.lcsim