FCAL timing smear

[ReBarsotti]

Hi everyone,

As you may know, we have been looking to improve the agreement of the MC and data in the FCAL photon reconstruction.

During our search we found that the timing distributions of the hits for the data (shown in the attached plot as the points) has tails that the MC (shown in the histogram) does not have.

We are working on correcting the core distribution to be more accurate but that still will not fix the disagreement in the tails that we see.

The attached plots show the MC and data distributions of the timing hits. For title "Number of Layers = 2" that is the
innermost two layers of the FCAL. For title "Number of Layers = 5" it is the hits in the layers 3-5, etc.
Please note, the y-axis is arbitrary as the histograms were normalized to 1.0 and the x axis is in nanoseconds.

This is using the 2018-08 data set, run numbers 050697-050800.

Thanks for any input or help you can provide!

[rjones30]

Hello Rebecca, This is not surprising, in view of how the hit times in the FCAL are being generated at present. The smeared values are the energy-weighted average of the quantity (t - z / c_eff) where t is the time that scintillation light was generated from a track fragment inside a block, and z is the longitudinal coordinate along the long axis of the block. Here I leave off the time offset for simplicity. I am using c_eff = 15cm/ns which is some attempt at approximating the dz/dt of a propagating light pulse emitted somewhere internal to the block and traveling toward the back face where it is collected. How accurate is this simple model, when compared to a detailed ray tracing simulation that takes into account the directionality of the Ckov cone, and the variation in path length due to the rectangular geometry of the block? This can be answered with an existing capability in hdgeant4 to directly generate and track individual Ckov rays. It is time consuming for normal production, but it can quickly give us an idea of whether what we have is useful as a starting point, before moving to MC smear. The other part is in mcsmear. I presume what we are doing there is just Gaussian smearing, right? It should be pretty straight-forward to generalize that to non-Gaussian distributions. -Richard Jones

…

On Wed, May 11, 2022 at 12:47 PM ReBarsotti ***@***.***> wrote: Hi everyone, As you may know, we have been looking to improve the agreement of the MC and data in the FCAL photon reconstruction. During our search we found that the timing distributions of the hits for the data (shown in the attached plot as the points) has tails that the MC (shown in the histogram) does not have. We are working on correcting the core distribution to be more accurate but that still will not fix the disagreement in the tails that we see. The attached plots show the MC and data distributions of the timing hits. For title "Number of Layers = 2" that is the innermost two layers of the FCAL. For title "Number of Layers = 5" it is the hits in the layers 3-5, etc. Please note, the y-axis is arbitrary as the histograms were normalized to 1.0 and the x axis is in nanoseconds. Thanks for any input or help you can provide! [image: tHit] <https://user-images.githubusercontent.com/40772859/167903474-a6e531e9-95a3-4a0e-8339-30510465c1e1.png> — Reply to this email directly, view it on GitHub <#242>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWBFTIQHVSCEGNB4YG3VJPQATANCNFSM5VVR3QHQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mashephe]

Hi Richard, The asymmetry in the tails in the data makes me think they arise from noise. And somehow our procedure for injecting noise from random triggers isn’t quite getting that right. I don’t think the origin in physics. Matt On May 11, 2022, at 12:36 PM, Richard Jones ***@***.***> wrote:  Hello Rebecca, This is not surprising, in view of how the hit times in the FCAL are being generated at present. The smeared values are the energy-weighted average of the quantity (t - z / c_eff) where t is the time that scintillation light was generated from a track fragment inside a block, and z is the longitudinal coordinate along the long axis of the block. Here I leave off the time offset for simplicity. I am using c_eff = 15cm/ns which is some attempt at approximating the dz/dt of a propagating light pulse emitted somewhere internal to the block and traveling toward the back face where it is collected. How accurate is this simple model, when compared to a detailed ray tracing simulation that takes into account the directionality of the Ckov cone, and the variation in path length due to the rectangular geometry of the block? This can be answered with an existing capability in hdgeant4 to directly generate and track individual Ckov rays. It is time consuming for normal production, but it can quickly give us an idea of whether what we have is useful as a starting point, before moving to MC smear. The other part is in mcsmear. I presume what we are doing there is just Gaussian smearing, right? It should be pretty straight-forward to generalize that to non-Gaussian distributions. -Richard Jones

On Wed, May 11, 2022 at 12:47 PM ReBarsotti ***@***.***> wrote: Hi everyone, As you may know, we have been looking to improve the agreement of the MC and data in the FCAL photon reconstruction. During our search we found that the timing distributions of the hits for the data (shown in the attached plot as the points) has tails that the MC (shown in the histogram) does not have. We are working on correcting the core distribution to be more accurate but that still will not fix the disagreement in the tails that we see. The attached plots show the MC and data distributions of the timing hits. For title "Number of Layers = 2" that is the innermost two layers of the FCAL. For title "Number of Layers = 5" it is the hits in the layers 3-5, etc. Please note, the y-axis is arbitrary as the histograms were normalized to 1.0 and the x axis is in nanoseconds. Thanks for any input or help you can provide! [image: tHit] <https://user-images.githubusercontent.com/40772859/167903474-a6e531e9-95a3-4a0e-8339-30510465c1e1.png> — Reply to this email directly, view it on GitHub <#242>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWBFTIQHVSCEGNB4YG3VJPQATANCNFSM5VVR3QHQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

— Reply to this email directly, view it on GitHub<#242 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADG5L2FRFLMGGMQ3H4I3QITVJPVZHANCNFSM5VVR3QHQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rjones30]

Matt, I didn't even notice the asymmetric structures out in the extreme left tails (past +/- 5ns). Is that what you mean by asymmetry in the tails? In my comments I was looking at the non-gaussian shoulders on the main peak. To my eye those look pretty symmetric in real data, and missing in the MC. That is probably light collection, wouldn't you agree? Is there one entry per block in a shower in this histogram, or one entry per shower? If it is per block, it might be interesting to see if there is a systematic correlation between the block time relative to the central block and the distance of the block from the center of gravity of the shower. That might set the scale for light collection variation since peripheral blocks should tend to see more light from the downstream end of the shower.

…

-Richard Jones On Thu, May 12, 2022 at 7:17 PM Matthew Shepherd ***@***.***> wrote:

Hi Richard, The asymmetry in the tails in the data makes me think they arise from noise. And somehow our procedure for injecting noise from random triggers isn’t quite getting that right. I don’t think the origin in physics. Matt On May 11, 2022, at 12:36 PM, Richard Jones ***@***.***> wrote:  Hello Rebecca, This is not surprising, in view of how the hit times in the FCAL are being generated at present. The smeared values are the energy-weighted average of the quantity (t - z / c_eff) where t is the time that scintillation light was generated from a track fragment inside a block, and z is the longitudinal coordinate along the long axis of the block. Here I leave off the time offset for simplicity. I am using c_eff = 15cm/ns which is some attempt at approximating the dz/dt of a propagating light pulse emitted somewhere internal to the block and traveling toward the back face where it is collected. How accurate is this simple model, when compared to a detailed ray tracing simulation that takes into account the directionality of the Ckov cone, and the variation in path length due to the rectangular geometry of the block? This can be answered with an existing capability in hdgeant4 to directly generate and track individual Ckov rays. It is time consuming for normal production, but it can quickly give us an idea of whether what we have is useful as a starting point, before moving to MC smear. The other part is in mcsmear. I presume what we are doing there is just Gaussian smearing, right? It should be pretty straight-forward to generalize that to non-Gaussian distributions. -Richard Jones On Wed, May 11, 2022 at 12:47 PM ReBarsotti ***@***.***> wrote: > Hi everyone, > > As you may know, we have been looking to improve the agreement of the MC > and data in the FCAL photon reconstruction. > > During our search we found that the timing distributions of the hits for > the data (shown in the attached plot as the points) has tails that the MC > (shown in the histogram) does not have. > > We are working on correcting the core distribution to be more accurate but > that still will not fix the disagreement in the tails that we see. > > The attached plots show the MC and data distributions of the timing hits. > For title "Number of Layers = 2" that is the > innermost two layers of the FCAL. For title "Number of Layers = 5" it is > the hits in the layers 3-5, etc. > Please note, the y-axis is arbitrary as the histograms were normalized to > 1.0 and the x axis is in nanoseconds. > > Thanks for any input or help you can provide! > > [image: tHit] > < https://user-images.githubusercontent.com/40772859/167903474-a6e531e9-95a3-4a0e-8339-30510465c1e1.png> > > — > Reply to this email directly, view it on GitHub > <#242>, or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AB3YKWBFTIQHVSCEGNB4YG3VJPQATANCNFSM5VVR3QHQ> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > — Reply to this email directly, view it on GitHub< #242 (comment)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADG5L2FRFLMGGMQ3H4I3QITVJPVZHANCNFSM5VVR3QHQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#242 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWDZPKTHPA2HETH2VJ3VJWGR5ANCNFSM5VVR3QHQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mashephe]

Yes, I'm most concerned about the extreme structures out past +/- 5 ns. They make a larger fraction of the total at inner radii (where we know we have some reconstruction issues). I also think they have the potential to interfere with clustering the most. I agree there are issues in the core distribution, but I think this can be corrected mostly with some semi ad-hoc smearing. I'm afraid if we don't get the extreme tails correct then we are not going to get efficiency correct. Any ideas on how to pursue this? I'm surprised in the MC there are absolutely zero hits out in the tails. It is not as if it is just underpopulated... there is nothing there. Is there something about the merging that would prevent such an out of time hit?

[rjones30]

If I have interpreted the x axis correctly, those pulses are coming 7 ns before the shower is expected to arrive. That is twice the length of the block in terms of light path inside lead glass. I can't think of anything in MC that would generate early pulses like that, and I am not surprised that random triggers don't show them either. Could there be an artifact in the fadc250 peak finding algorithm that generates spurious early leading edges in some cases? What is the time reference for these plots? It might be easier to explain a late reference time than an early FCAL pulse time. -Richard Jones

…

On Tue, May 17, 2022 at 10:28 AM Matthew Shepherd ***@***.***> wrote: Yes, I'm most concerned about the extreme structures out past +/- 5 ns. They make a larger fraction of the total at inner radii (where we know we have some reconstruction issues). I also think they have the potential to interfere with clustering the most. I agree there are issues in the core distribution, but I think this can be corrected mostly with some semi ad-hoc smearing. I'm afraid if we don't get the extreme tails correct then we are not going to get efficiency correct. Any ideas on how to pursue this? I'm surprised in the MC there are absolutely zero hits out in the tails. It is not as if it is just underpopulated... there is nothing there. Is there something about the merging that would prevent such an out of time hit? — Reply to this email directly, view it on GitHub <#242 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWBBJYJ4EPHZ4X7GUZLVKOUJ3ANCNFSM5VVR3QHQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mashephe]

On May 17, 2022, at 11:53 AM, Richard Jones ***@***.***> wrote: and I am not surprised that random triggers don't show them either.

I would expect them to be there

Could there be an artifact in the fadc250 peak finding algorithm that generates spurious early leading edges in some cases? What is the time reference for these plots?

The time reference for these plots is the RF time, which I think should be the same time reference used to define the readout window. There can certainly be early pulses that may make the FADC blind to the true peak. I believe that the peak finding algorithm is triggered on having two consecutive FADC samples above the DAQ threshold. One can have noise generated by the switching supply in the base or also just EM background that arrives early in the readout window. I should correct my previous statement. If you zoom in on the Layers = 2 plot (top left), you see there is some solid histogram out away from the core, but the quantity of it is very small. It seems to vanish in the outer layers while the tails in data persist. Matt

[rjones30]

Matt, what about this possibility: the peak at 13.5ns is just 8ns away from the main peak at 21.5ns, so it is an echo of the main peak with the RF time off by two bunches. One would also expect one at 17.5ns, but it might be hidden in the shape of the tail. This would not be noticed in the random triggers because there is no vertex to tag the trigger RF time. -Richard Jones On Tue, May 17, 2022 at 12:09 PM Matthew Shepherd ***@***.***> wrote:

…

> On May 17, 2022, at 11:53 AM, Richard Jones ***@***.***> wrote: > and I am not surprised > that random triggers don't show them either. I would expect them to be there > Could there be an artifact in > the fadc250 peak finding algorithm that generates spurious early leading > edges in some cases? What is the time reference for these plots? The time reference for these plots is the RF time, which I think should be the same time reference used to define the readout window. There can certainly be early pulses that may make the FADC blind to the true peak. I believe that the peak finding algorithm is triggered on having two consecutive FADC samples above the DAQ threshold. One can have noise generated by the switching supply in the base or also just EM background that arrives early in the readout window. I should correct my previous statement. If you zoom in on the Layers = 2 plot (top left), you see there is some solid histogram out away from the core, but the quantity of it is very small. It seems to vanish in the outer layers while the tails in data persist. Matt — Reply to this email directly, view it on GitHub <#242 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWBDOQEYW5OYNMQYU33VKPAELANCNFSM5VVR3QHQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ReBarsotti]

Here is the top left plot (FCAL layers = 2) with a log scale on the y-axis:

[mashephe]

Hi Richard, Rebecca posted a log plot of the same distribution. You can indeed see the peaks in data at neighboring RF bunches. I think this makes senses: EM background that is out of time with the primary bunch. This appears to not be modeled (or is severely underpopulated) in the MC. Any idea why? Matt

…

On May 17, 2022, at 12:19 PM, Richard Jones ***@***.***> wrote: Matt, what about this possibility: the peak at 13.5ns is just 8ns away from the main peak at 21.5ns, so it is an echo of the main peak with the RF time off by two bunches. One would also expect one at 17.5ns, but it might be hidden in the shape of the tail. This would not be noticed in the random triggers because there is no vertex to tag the trigger RF time. -Richard Jones On Tue, May 17, 2022 at 12:09 PM Matthew Shepherd ***@***.***> wrote: > > > > On May 17, 2022, at 11:53 AM, Richard Jones ***@***.***> wrote: > > > and I am not surprised > > that random triggers don't show them either. > > I would expect them to be there > > > Could there be an artifact in > > the fadc250 peak finding algorithm that generates spurious early leading > > edges in some cases? What is the time reference for these plots? > > The time reference for these plots is the RF time, which I think should be > the same time reference used to define the readout window. > > There can certainly be early pulses that may make the FADC blind to the > true peak. I believe that the peak finding algorithm is triggered on having > two consecutive FADC samples above the DAQ threshold. One can have noise > generated by the switching supply in the base or also just EM background > that arrives early in the readout window. > > I should correct my previous statement. If you zoom in on the Layers = 2 > plot (top left), you see there is some solid histogram out away from the > core, but the quantity of it is very small. It seems to vanish in the outer > layers while the tails in data persist. > > Matt > > > — > Reply to this email directly, view it on GitHub > <#242 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB3YKWBDOQEYW5OYNMQYU33VKPAELANCNFSM5VVR3QHQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[rjones30]

This appears to not be modeled (or is severely underpopulated) in the MC. Any idea why?

I believe it has been turned off in your run of the MC. To turn it on, look at the BGRATE and BGGATE cards in control.in. The comments in control.in provide a guide to their meaning and use. -Richard Jones On Sun, May 22, 2022 at 6:25 AM Matthew Shepherd ***@***.***> wrote:

…

Hi Richard, Rebecca posted a log plot of the same distribution. You can indeed see the peaks in data at neighboring RF bunches. I think this makes senses: EM background that is out of time with the primary bunch. This appears to not be modeled (or is severely underpopulated) in the MC. Any idea why? Matt > On May 17, 2022, at 12:19 PM, Richard Jones ***@***.***> wrote: > > > Matt, what about this possibility: the peak at 13.5ns is just 8ns away from > the main peak at 21.5ns, so it is an echo of the main peak with the RF time > off by two bunches. One would also expect one at 17.5ns, but it might be > hidden in the shape of the tail. This would not be noticed in the random > triggers because there is no vertex to tag the trigger RF time. > -Richard Jones > > On Tue, May 17, 2022 at 12:09 PM Matthew Shepherd ***@***.***> > wrote: > > > > > > > > On May 17, 2022, at 11:53 AM, Richard Jones ***@***.***> wrote: > > > > > and I am not surprised > > > that random triggers don't show them either. > > > > I would expect them to be there > > > > > Could there be an artifact in > > > the fadc250 peak finding algorithm that generates spurious early leading > > > edges in some cases? What is the time reference for these plots? > > > > The time reference for these plots is the RF time, which I think should be > > the same time reference used to define the readout window. > > > > There can certainly be early pulses that may make the FADC blind to the > > true peak. I believe that the peak finding algorithm is triggered on having > > two consecutive FADC samples above the DAQ threshold. One can have noise > > generated by the switching supply in the base or also just EM background > > that arrives early in the readout window. > > > > I should correct my previous statement. If you zoom in on the Layers = 2 > > plot (top left), you see there is some solid histogram out away from the > > core, but the quantity of it is very small. It seems to vanish in the outer > > layers while the tails in data persist. > > > > Matt > > > > > > — > > Reply to this email directly, view it on GitHub > > < #242 (comment)>, > > or unsubscribe > > < https://github.com/notifications/unsubscribe-auth/AB3YKWBDOQEYW5OYNMQYU33VKPAELANCNFSM5VVR3QHQ> > > . > > You are receiving this because you commented.Message ID: > > ***@***.***> > > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented. > — Reply to this email directly, view it on GitHub <#242 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWHPUHCBXAMYCBZBSW3VLIDP7ANCNFSM5VVR3QHQ> . You are receiving this because you commented.Message ID: ***@***.***>

[rjones30]

This appears to not be modeled (or is severely underpopulated) in the MC. Any idea why?

I believe those BGRATE and BGGATE cards are turned off for a reason, because these out-of-time tags should be injected from the random triggers that are being merged into the MC events by mcsmear. Can you confirm that you have random triggers merging enabled in mcsmear? If so, there may be an issue with how the clock in the random triggers hits is being synchronized to the clock in the MC event. If care is not taken to sync the two clocks, the "picket-fence'" pattern in the out-of-time tags will be smeared out flat. The random hits merging code in mcsmear attempts to do this correctly, but I don't know how extensively it has been tested.

…

-Richard Jones

-Richard Jones

On Sun, May 22, 2022 at 7:00 AM Richard Jones ***@***.***> wrote: This appears to not be modeled (or is severely underpopulated) in the MC. > Any idea why? > I believe it has been turned off in your run of the MC. To turn it on, look at the BGRATE and BGGATE cards in control.in. The comments in control.in provide a guide to their meaning and use. -Richard Jones On Sun, May 22, 2022 at 6:25 AM Matthew Shepherd ***@***.***> wrote: > > Hi Richard, > > Rebecca posted a log plot of the same distribution. > > You can indeed see the peaks in data at neighboring RF bunches. I think > this makes senses: EM background that is out of time with the primary > bunch. > > This appears to not be modeled (or is severely underpopulated) in the MC. > Any idea why? > > Matt > > > > On May 17, 2022, at 12:19 PM, Richard Jones ***@***.***> wrote: > > > > > > Matt, what about this possibility: the peak at 13.5ns is just 8ns away > from > > the main peak at 21.5ns, so it is an echo of the main peak with the RF > time > > off by two bunches. One would also expect one at 17.5ns, but it might > be > > hidden in the shape of the tail. This would not be noticed in the > random > > triggers because there is no vertex to tag the trigger RF time. > > -Richard Jones > > > > On Tue, May 17, 2022 at 12:09 PM Matthew Shepherd ***@***.***> > > wrote: > > > > > > > > > > > > On May 17, 2022, at 11:53 AM, Richard Jones ***@***.***> wrote: > > > > > > > and I am not surprised > > > > that random triggers don't show them either. > > > > > > I would expect them to be there > > > > > > > Could there be an artifact in > > > > the fadc250 peak finding algorithm that generates spurious early > leading > > > > edges in some cases? What is the time reference for these plots? > > > > > > The time reference for these plots is the RF time, which I think > should be > > > the same time reference used to define the readout window. > > > > > > There can certainly be early pulses that may make the FADC blind to > the > > > true peak. I believe that the peak finding algorithm is triggered on > having > > > two consecutive FADC samples above the DAQ threshold. One can have > noise > > > generated by the switching supply in the base or also just EM > background > > > that arrives early in the readout window. > > > > > > I should correct my previous statement. If you zoom in on the Layers > = 2 > > > plot (top left), you see there is some solid histogram out away from > the > > > core, but the quantity of it is very small. It seems to vanish in the > outer > > > layers while the tails in data persist. > > > > > > Matt > > > > > > > > > — > > > Reply to this email directly, view it on GitHub > > > < > #242 (comment)>, > > > > or unsubscribe > > > < > https://github.com/notifications/unsubscribe-auth/AB3YKWBDOQEYW5OYNMQYU33VKPAELANCNFSM5VVR3QHQ> > > > > . > > > You are receiving this because you commented.Message ID: > > > ***@***.***> > > > > > — > > Reply to this email directly, view it on GitHub, or unsubscribe. > > You are receiving this because you commented. > > > > — > Reply to this email directly, view it on GitHub > <#242 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB3YKWHPUHCBXAMYCBZBSW3VLIDP7ANCNFSM5VVR3QHQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[ReBarsotti]

Hi Richard,
This does include random triggers. This particular set was run on OSG using a standard release and random noise. Also, the "picket-fence" pattern is visible in the hit timing distribution.
Thanks!

[sdobbs]

Hi all,

I have a hard time believing that the problem is inherent to the random trigger background events, unless there is some additional noise that's created in events that pass the physics trigger? This should be correlated with the reaction that causes the event, though, not with beam-related backgrounds.

It should be fairly straightforward to check to see what happens if we turn off merging of hits close in time for the FCAL (this is pretty much the only transformation of hit parameters that is applied, and i think that hits in the same channel to within about 70ns are merged?). Richard, can you suggest if there's an easy way to do this? I get a little lost in the hit merging code. Maybe setting fcal_integration_window_ns to some small value would do this?

It might also be interesting to look at some data events that have a hit in this side peak (for example) to see if there's any commonalities in them. Maybe @ReBarsotti could supply a list of 10-20 events we could look at?

[sdobbs]

Also, I had previously made a couple suggestions that I think should help us tell how much of this effect is due to issues with background modelling:

It would be interesting to see the same plots in the OP, for a given layer AND

• slices of the shower energy
• different ranges of the number of hits in the shower

So, for each of these, you could imagine 4 different ranges for each of the 4 different layers, soa total of 16 timing plots

[rjones30]

This does include random triggers. This particular set was run on OSG using a standard release and random noise. Also, the "picket-fence" pattern is visible in the hit timing distribution.

That is surprising, because I don't see the picket fence in your FCAL-RF timing distribution, which you should unless you are using "cheat" information in the MC to always select the true photon and never accept a combo that meets all of the analysis criteria, but happens to use an accidental tag. Could it just be that the MC statistics are too small? You might not know how to answer this question, but Beni (or someone else) might: is there some way a person analyzing MC events can ALWAYS get the true DBeamPhoton in Monte Carlo? i.e. the one that actually generated the event in the MC sim? That would be useful for warm-up exercises, but is not allowed when you are trying to do physics simulation because you end up with things like this: timing distributions in MC that do not look like the real data. But if hooks for this always-true-tag are available in the analysis toolkit, I can imagine that it is nigh irresistible for people to always analyze against the true tag and ignore the accidentals in MC.

…

-Richard Jones

On Mon, May 23, 2022 at 10:22 AM ReBarsotti ***@***.***> wrote: Hi Richard, This does include random triggers. This particular set was run on OSG using a standard release and random noise. Also, the "picket-fence" pattern is visible in the hit timing distribution. Thanks! — Reply to this email directly, view it on GitHub <#242 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWEPC5TBVWF26VZ2EWLVLOIBRANCNFSM5VVR3QHQ> . You are receiving this because you commented.Message ID: ***@***.***>