FCAL timing smear #242
Comments
|
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: ***@***.***>
|
|
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: ***@***.***>
|
|
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:
***@***.***>
|
|
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? |
|
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:
***@***.***>
|
|
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
|
|
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:
***@***.***>
|
|
Here is the top left plot (FCAL layers = 2) with a log scale on the y-axis: |
|
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.
|
|
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:
***@***.***>
|
|
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:
> ***@***.***>
>
|
|
Hi Richard, |
|
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 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? |
|
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
So, for each of these, you could imagine 4 different ranges for each of the 4 different layers, soa total of 16 timing plots |
|
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:
***@***.***>
|
This is provided with the "TAGGEDMCGEN" or "TRUTH" tags for DBeamPhotons, depending on if you wanted the reconstructed (if available) or thrown values. FWIW, when I looked at the random hits, the "picket fence" is much more visible when using the RF time as a reference. I don't think that Rebecca is doing that (though it depends on the binning) |
|
Thanks, Sean. This means that the RF sync is actually working in the random
triggers merging. That is what I intended, but that doesn't necessarily
mean that it works!
FWIW, when I looked at the random hits, the "picket fence" is much more
visible when using the RF time as a reference. I don't think that Rebecca
is doing that (though it depends on the binning)
If you are referring to the FCAL timing plot, the label indicates "FCAL
time - RF". Doesn't this mean relative to the RF time?
-Richard Jones
…On Mon, May 23, 2022 at 1:37 PM Sean Dobbs ***@***.***> wrote:
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?
This is provided with the "TAGGEDMCGEN" or "TRUTH" tags for DBeamPhotons,
depending on if you wanted the reconstructed (if available) or thrown
values.
FWIW, when I looked at the random hits, the "picket fence" is much more
visible when using the RF time as a reference. I don't think that Rebecca
is doing that (though it depends on the binning)
Ref: JeffersonLab/HDGeant4#196 (comment)
<JeffersonLab/HDGeant4#196 (comment)>
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWCSCTTLUB3CE2GVFELVLO64BANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yes, in the plots that I linked to, these were the random trigger events collected in data, so I just picked some nominal RF time that was stored in the data stream (a DRFTime object). I had to remind myself that @ReBarsotti was plotting a hit time - RF time distribution, and I'm guessing that this reference time is the RF bucket that the event is expected to come from based on the reconstructed final state particles (DEventRFBunch - but please correct me if I'm wrong!). That would give the right flight time that we see here, I think. |
|
Correct, this is the time of the hit in the FCAL minus the RF Time. If I plot only the RFTime there is a clear picket fence structure. |
|
Rebecca, could you also verify that you are not using the switches
"TAGGEDMCGEN" or "TRUTH" tags for DBeamPhotons? Those are ok for warm-up
studies, but if you want to compare data timing distributions with real
data you cannot have these switches turned on.
…-Richard Jones
On Tue, May 24, 2022 at 2:20 PM ReBarsotti ***@***.***> wrote:
Correct, this is the time of the hit in the FCAL minus the RF Time. If I
plot only the RFTime there is a clear picket fence structure.
I will try to supply the requested plots and a list of some events in the
side regions in the next day or so and post them in this thread.
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWCUP6FUGSSX72UYEFTVLUMV5ANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I'm relatively confident that I am not using those tags, but I will check! |
|
Attached are the plots Sean requested. If the DBeamPhotons flags would be used at the plugin level, I have verified that they were not used.
. |
|
If the DBeamPhotons flags would be used at the plugin level, I have
verified that they were not used.
I am not sure about, "at the plugin level". Aren't you running the
reconstruction of MC as well? I believe the MC reconstruction stage is
where this flag would be applied. It is too late after that, isn't it?
-Richard Jones
…On Wed, May 25, 2022 at 10:25 AM ReBarsotti ***@***.***> wrote:
Attached are the plots Sean requested. If the DBeamPhotons flags would be
used at the plugin level, I have verified that they were not used.
As for the list of 10 or so events, what particular information were you
interested to see? (As you can imagine there are many quantities for each
shower so I don't want to flood you with info you weren't looking for)
[image: hitBracket1]
<https://user-images.githubusercontent.com/40772859/170285483-f2359d7f-359c-4ee7-af0b-30913383dbcd.png>
[image: hitBracket2]
<https://user-images.githubusercontent.com/40772859/170285491-0c818309-007c-488f-bf3b-a7f175720395.png>
[image: hitBracket3]
<https://user-images.githubusercontent.com/40772859/170285492-222abf7b-abd1-45b2-8407-37e9cc337355.png>
[image: hitBracket4]
<https://user-images.githubusercontent.com/40772859/170285493-bf9e2163-1078-4ea4-afb2-941f09dc9842.png>
[image: OG]
<https://user-images.githubusercontent.com/40772859/170285496-e8a6095c-f3dc-42b0-9010-690387228adb.png>
[image: showerBracket1]
<https://user-images.githubusercontent.com/40772859/170285498-d3f21bdb-5782-4793-b2a1-1e3488d3ab52.png>
[image: showerBracket2]
<https://user-images.githubusercontent.com/40772859/170285501-7e0043e7-19c9-4cfc-a21e-19b08b6591c8.png>
[image: showerBracket3]
<https://user-images.githubusercontent.com/40772859/170285502-84bf61f5-3b2d-47f3-9f71-5aa4211d793c.png>
[image: showerBracket4]
<https://user-images.githubusercontent.com/40772859/170285504-bccab1a7-f46e-4a7a-a870-12bf61c809b0.png>
.
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWGF53H7DAEPTLJWI6LVLYZ4JANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
In that case, these were reconstructed using the reaction option in the MC Submit Form for OSG -- so standard reconstruction. Unless these are default flags, there is no reason they would have been used. |
Also, I think you are just plotting the calibrated FCAL times, right? So there's no reference to the beam photon in any of these plots. |
Thanks a lot for the plots! I don't see any obvious trends, but will think more. For the 10+ events could you please just give the run/event numbers? I can look at them myself. |
|
Also, I think you are just plotting the calibrated FCAL times, right? So
there's no reference to the beam photon in any of these plots.
This is not true. Without the beam photon you don't know which RF bucket to
take, every 4 ns.
-Richard Jones
…On Wed, May 25, 2022 at 10:34 AM Sean Dobbs ***@***.***> wrote:
In that case, these were reconstructed using the reaction option in the MC
Submit Form for OSG -- so standard reconstruction. Unless these are default
flags, there is no reason they would have been used.
Also, I think you are just plotting the calibrated FCAL times, right? So
there's no reference to the beam photon in any of these plots.
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWEGM2KPWHA73PKEJTDVLY3ADANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Before I go too far out on a limb with claims of how the simulation
behaves, let me make some plots of FCAL hit time - RF time myself and check
that I see the picket fence that I claim should be there. There might be a
bug in hdgeant4.
-Richard Jones
…On Wed, May 25, 2022 at 10:39 AM Richard Jones ***@***.***> wrote:
Also, I think you are just plotting the calibrated FCAL times, right? So
> there's no reference to the beam photon in any of these plots.
>
This is not true. Without the beam photon you don't know which RF bucket
to take, every 4 ns.
-Richard Jones
On Wed, May 25, 2022 at 10:34 AM Sean Dobbs ***@***.***>
wrote:
> In that case, these were reconstructed using the reaction option in the
> MC Submit Form for OSG -- so standard reconstruction. Unless these are
> default flags, there is no reason they would have been used.
>
> Also, I think you are just plotting the calibrated FCAL times, right? So
> there's no reference to the beam photon in any of these plots.
>
> —
> Reply to this email directly, view it on GitHub
> <#242 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB3YKWEGM2KPWHA73PKEJTDVLY3ADANCNFSM5VVR3QHQ>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
I'm not sure if it is relevant, but Rebecca is working with exclusive omega events. These have a tight chi^2 cut on the kinematic fit and only have one candidate beam photon. We are then looking at all FCAL hits in the context of these events where we have a good idea of what the beam photon is. This is used as the RF time for the delta T plots.
Matt
… On May 25, 2022, at 12:58 PM, Richard Jones ***@***.***> wrote:
Before I go too far out on a limb with claims of how the simulation
behaves, let me make some plots of FCAL hit time - RF time myself and check
that I see the picket fence that I claim should be there. There might be a
bug in hdgeant4.
-Richard Jones
On Wed, May 25, 2022 at 10:39 AM Richard Jones ***@***.***> wrote:
> Also, I think you are just plotting the calibrated FCAL times, right? So
>> there's no reference to the beam photon in any of these plots.
>>
>
> This is not true. Without the beam photon you don't know which RF bucket
> to take, every 4 ns.
> -Richard Jones
>
> On Wed, May 25, 2022 at 10:34 AM Sean Dobbs ***@***.***>
> wrote:
>
>> In that case, these were reconstructed using the reaction option in the
>> MC Submit Form for OSG -- so standard reconstruction. Unless these are
>> default flags, there is no reason they would have been used.
>>
>> Also, I think you are just plotting the calibrated FCAL times, right? So
>> there's no reference to the beam photon in any of these plots.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#242 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AB3YKWEGM2KPWHA73PKEJTDVLY3ADANCNFSM5VVR3QHQ>
>> .
>> 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.
|
|
Matt, understood. That is the same situation in the real data, but my
interpretation of the out-of-time peaks in the FCAL time - RF time
histograms for real data is that sometimes even with all of those
constraints, the photons in FCAL showers come from a different beam bucket
than the one identified by the candidate tag photon. Not so in the MC, even
though Rebecca shows pretty large statistics, there is no evidence of ever
seeing FCAL hits in time with a different beam bucket than the one chosen
as the candidate tag. This does not look like what I remember seeing for
the same situation when I initially examined the FCAL simulation output. It
looks to me like a bug has crept in at some point since I first examined
these time spectra.
…-Richard Jones
On Wed, May 25, 2022 at 1:55 PM Matthew Shepherd ***@***.***>
wrote:
I'm not sure if it is relevant, but Rebecca is working with exclusive
omega events. These have a tight chi^2 cut on the kinematic fit and only
have one candidate beam photon. We are then looking at all FCAL hits in the
context of these events where we have a good idea of what the beam photon
is. This is used as the RF time for the delta T plots.
Matt
> On May 25, 2022, at 12:58 PM, Richard Jones ***@***.***> wrote:
>
>
> Before I go too far out on a limb with claims of how the simulation
> behaves, let me make some plots of FCAL hit time - RF time myself and
check
> that I see the picket fence that I claim should be there. There might be
a
> bug in hdgeant4.
> -Richard Jones
>
> On Wed, May 25, 2022 at 10:39 AM Richard Jones ***@***.***> wrote:
>
> > Also, I think you are just plotting the calibrated FCAL times, right?
So
> >> there's no reference to the beam photon in any of these plots.
> >>
> >
> > This is not true. Without the beam photon you don't know which RF
bucket
> > to take, every 4 ns.
> > -Richard Jones
> >
> > On Wed, May 25, 2022 at 10:34 AM Sean Dobbs ***@***.***>
> > wrote:
> >
> >> In that case, these were reconstructed using the reaction option in
the
> >> MC Submit Form for OSG -- so standard reconstruction. Unless these are
> >> default flags, there is no reason they would have been used.
> >>
> >> Also, I think you are just plotting the calibrated FCAL times, right?
So
> >> there's no reference to the beam photon in any of these plots.
> >>
> >> —
> >> Reply to this email directly, view it on GitHub
> >> <
#242 (comment)
>,
> >> or unsubscribe
> >> <
https://github.com/notifications/unsubscribe-auth/AB3YKWEGM2KPWHA73PKEJTDVLY3ADANCNFSM5VVR3QHQ
>
> >> .
> >> 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/AB3YKWDHYC4JTUTA3STDQL3VLZSPPANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Richard,
Yes, I agree with your assessment.
Another point of information (which doesn't contradict anything you say): Rebecca is plotting delta t for all hits (not just those in showers) in the context of these events where beam photon of interest is known with good probability. The data suggest some hits come from neighboring beam bunches, which is not surprising. What is surprising, as you note, is that MC strongly under-predicts the number of out-of-time hits.
The root of this investigation is trying to understand why MC doesn't replicate efficiency loss in beam region. The hypothesis is that out of time hits might affect clustering. This led us to look at the time distribution of all hits (not just those in the shower).
Matt
… On May 25, 2022, at 2:16 PM, Richard Jones ***@***.***> wrote:
Matt, understood. That is the same situation in the real data, but my
interpretation of the out-of-time peaks in the FCAL time - RF time
histograms for real data is that sometimes even with all of those
constraints, the photons in FCAL showers come from a different beam bucket
than the one identified by the candidate tag photon. Not so in the MC, even
though Rebecca shows pretty large statistics, there is no evidence of ever
seeing FCAL hits in time with a different beam bucket than the one chosen
as the candidate tag. This does not look like what I remember seeing for
the same situation when I initially examined the FCAL simulation output. It
looks to me like a bug has crept in at some point since I first examined
these time spectra.
-Richard Jones
On Wed, May 25, 2022 at 1:55 PM Matthew Shepherd ***@***.***>
wrote:
>
> I'm not sure if it is relevant, but Rebecca is working with exclusive
> omega events. These have a tight chi^2 cut on the kinematic fit and only
> have one candidate beam photon. We are then looking at all FCAL hits in the
> context of these events where we have a good idea of what the beam photon
> is. This is used as the RF time for the delta T plots.
>
> Matt
>
>
> > On May 25, 2022, at 12:58 PM, Richard Jones ***@***.***> wrote:
> >
> >
> > Before I go too far out on a limb with claims of how the simulation
> > behaves, let me make some plots of FCAL hit time - RF time myself and
> check
> > that I see the picket fence that I claim should be there. There might be
> a
> > bug in hdgeant4.
> > -Richard Jones
> >
> > On Wed, May 25, 2022 at 10:39 AM Richard Jones ***@***.***> wrote:
> >
> > > Also, I think you are just plotting the calibrated FCAL times, right?
> So
> > >> there's no reference to the beam photon in any of these plots.
> > >>
> > >
> > > This is not true. Without the beam photon you don't know which RF
> bucket
> > > to take, every 4 ns.
> > > -Richard Jones
> > >
> > > On Wed, May 25, 2022 at 10:34 AM Sean Dobbs ***@***.***>
> > > wrote:
> > >
> > >> In that case, these were reconstructed using the reaction option in
> the
> > >> MC Submit Form for OSG -- so standard reconstruction. Unless these are
> > >> default flags, there is no reason they would have been used.
> > >>
> > >> Also, I think you are just plotting the calibrated FCAL times, right?
> So
> > >> there's no reference to the beam photon in any of these plots.
> > >>
> > >> —
> > >> Reply to this email directly, view it on GitHub
> > >> <
> #242 (comment)
> >,
> > >> or unsubscribe
> > >> <
> https://github.com/notifications/unsubscribe-auth/AB3YKWEGM2KPWHA73PKEJTDVLY3ADANCNFSM5VVR3QHQ
> >
> > >> .
> > >> 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/AB3YKWDHYC4JTUTA3STDQL3VLZSPPANCNFSM5VVR3QHQ>
> .
> 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.
|
|
Rebecca is plotting delta t for all hits (not just those in showers) in
the context of these events where beam photon of interest is known with
good probability. The data suggest some hits come from neighboring beam
bunches, which is not surprising. What is surprising, as you note, is that
MC strongly under-predicts the number of out-of-time hits.
Ok, this is important, thanks. I am looking into it now.
-Richard J.
On Thu, May 26, 2022 at 9:22 AM Matthew Shepherd ***@***.***>
wrote:
…
Richard,
Yes, I agree with your assessment.
Another point of information (which doesn't contradict anything you say):
Rebecca is plotting delta t for all hits (not just those in showers) in the
context of these events where beam photon of interest is known with good
probability. The data suggest some hits come from neighboring beam bunches,
which is not surprising. What is surprising, as you note, is that MC
strongly under-predicts the number of out-of-time hits.
The root of this investigation is trying to understand why MC doesn't
replicate efficiency loss in beam region. The hypothesis is that out of
time hits might affect clustering. This led us to look at the time
distribution of all hits (not just those in the shower).
Matt
> On May 25, 2022, at 2:16 PM, Richard Jones ***@***.***> wrote:
>
>
> Matt, understood. That is the same situation in the real data, but my
> interpretation of the out-of-time peaks in the FCAL time - RF time
> histograms for real data is that sometimes even with all of those
> constraints, the photons in FCAL showers come from a different beam
bucket
> than the one identified by the candidate tag photon. Not so in the MC,
even
> though Rebecca shows pretty large statistics, there is no evidence of
ever
> seeing FCAL hits in time with a different beam bucket than the one chosen
> as the candidate tag. This does not look like what I remember seeing for
> the same situation when I initially examined the FCAL simulation output.
It
> looks to me like a bug has crept in at some point since I first examined
> these time spectra.
>
> -Richard Jones
>
> On Wed, May 25, 2022 at 1:55 PM Matthew Shepherd ***@***.***>
> wrote:
>
> >
> > I'm not sure if it is relevant, but Rebecca is working with exclusive
> > omega events. These have a tight chi^2 cut on the kinematic fit and
only
> > have one candidate beam photon. We are then looking at all FCAL hits
in the
> > context of these events where we have a good idea of what the beam
photon
> > is. This is used as the RF time for the delta T plots.
> >
> > Matt
> >
> >
> > > On May 25, 2022, at 12:58 PM, Richard Jones ***@***.***> wrote:
> > >
> > >
> > > Before I go too far out on a limb with claims of how the simulation
> > > behaves, let me make some plots of FCAL hit time - RF time myself and
> > check
> > > that I see the picket fence that I claim should be there. There
might be
> > a
> > > bug in hdgeant4.
> > > -Richard Jones
> > >
> > > On Wed, May 25, 2022 at 10:39 AM Richard Jones ***@***.***> wrote:
> > >
> > > > Also, I think you are just plotting the calibrated FCAL times,
right?
> > So
> > > >> there's no reference to the beam photon in any of these plots.
> > > >>
> > > >
> > > > This is not true. Without the beam photon you don't know which RF
> > bucket
> > > > to take, every 4 ns.
> > > > -Richard Jones
> > > >
> > > > On Wed, May 25, 2022 at 10:34 AM Sean Dobbs ***@***.***>
> > > > wrote:
> > > >
> > > >> In that case, these were reconstructed using the reaction option
in
> > the
> > > >> MC Submit Form for OSG -- so standard reconstruction. Unless
these are
> > > >> default flags, there is no reason they would have been used.
> > > >>
> > > >> Also, I think you are just plotting the calibrated FCAL times,
right?
> > So
> > > >> there's no reference to the beam photon in any of these plots.
> > > >>
> > > >> —
> > > >> Reply to this email directly, view it on GitHub
> > > >> <
> >
#242 (comment)
> > >,
> > > >> or unsubscribe
> > > >> <
> >
https://github.com/notifications/unsubscribe-auth/AB3YKWEGM2KPWHA73PKEJTDVLY3ADANCNFSM5VVR3QHQ
> > >
> > > >> .
> > > >> 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/AB3YKWDHYC4JTUTA3STDQL3VLZSPPANCNFSM5VVR3QHQ
>
> > .
> > 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/AB3YKWE7KOOHPJNBBASJSXDVL53KVANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Rebecca,
Here is my first attempt to reproduce plots similar to what you show,
except using bggen simulation. Here I am taking a combo of every fcal hit
with every tag, so no cuts have been applied except that something in the
event passed the physics trigger. Without any cuts, the association with
the true tag is very weak, so this is just a starting point. My next step
would be to require a recoil proton and make some sort of total energy cut,
to start moving toward a final state selection like what you are doing. If
you could share the plugin + switches you use to produce the FCal timing
distributions you showed, that would make this process go a lot faster.
-Richard
|
|
Richard,
I wasn’t able to see the images.
Matt
|
|
Same here, the images are not visible. Also, I should note that the original plot was for ALL hits in the detector, even if not included in a shower. The second set of plots that Sean requested, I used only true photons. So you can see that this a problem that persists regardless of shower type. As for the plugin I was using, I will put it on the ifarm at /u/home/rebars/ShowerShapeTree |
|
I updated the entry directly on the github issues page. If you go there,
you should be able to click the links in my message and see the plots.
-Richard J.
… Message ID: ***@***.***>
|
|
It seems like the interesting thing to do would be to look at the time difference of every FCAL hit with the true tag. This would let one see how the hits populate the neighboring bunches outside of the true one. This must be pretty close to what we are doing with data. |
|
I set up a simulation + reconstruction + ReactionFilter + DSelector chain for exclusive omega(3pi) at 8.5 GeV. I generated 500k signal events using genr8 and simulated them in hdgeant4 for run 50986. With a ReactionFilter 1_14__7_8_9 flags B0_M7 and a kinematic fit CL cut at 1e-6, I get 9075 events reconstructed, with a mean of 6 combos per event. Most of this combo redundancy is from tagging accidentals. In this study, I turned off the internal electromagnetic background in hdgeant4, and used random triggers merging in mcsmear to include the effects of accidentals in the detector and tagger. For every event that passes the kinematic cut I go back and plot the t - tRF for all hits in the inner region of the fcal. Here is what I see for all hits in one of the innermost fcal blocks. The peak height and width for the side peaks look comparable to what you are seeing in the real data at around t0 - 8ns. What I don't understand is why your timing distribution tails off as you go below t0-10ns or above t0+10ns. Is there a limit to the time range you are considering? |
|
I believe the sample we are using is written by the omega_skim plugin and uses the analysis cuts specified here: It is a tight CL cut (5%) and we only take events where one combo passes the cut. I don't think any of this should affect the timing of other stuff in the event though. Can you share your MC files? Maybe Rebecca should run on those and see what kind of plots the same code she has been using produces on those files. |
|
Ok, here is a sample of 10M omega(3pi) signal MonteCarlo (genr8) simulated
for run 50986 with random triggers merged from runs in the vicinity of
50986. They are still finishing simulation, so a few of the files may still
be missing for a couple more hours. You can download them or use them
in-place (with xrootd) as you wish. Here are some remote access handles for
accessing them remotely, where the XXX symbol is a serial number in the
range 000...999.
-
http://grinch.phys.uconn.edu:2880/Gluex/simulation/omega3pi/test10M_XXX_smeared.hddm
-
https://grinch.phys.uconn.edu:2843/Gluex/simulation/omega3pi/test10M_XXX_smeared.hddm
- root://
grinch.phys.uconn.edu/Gluex/simulation/omega3pi/test10M_XXX_smeared.hddm
…-Richard Jones
On Thu, Jun 2, 2022 at 12:20 PM Matthew Shepherd ***@***.***> wrote:
I believe the sample we are using is written by the omega_skim plugin and
uses the analysis cuts specified here:
https://github.com/JeffersonLab/halld_recon/blob/master/src/plugins/Utilities/omega_skim/DReaction_factory_OmegaSkim.cc
It is a tight CL cut (5%) and we only take events where one combo passes
the cut. I don't think any of this should affect the timing of other stuff
in the event though.
Can you share your MC files? Maybe Rebecca should run on those and see
what kind of plots the same code she has been using produces on those files.
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWGCDRH22ULCVHXGUWLVNDNOJANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Richard, |
|
What conclusions can we draw from this? Are there still outstanding
features in the fcal timing real data distribution that simulation is
missing?
-Richard Jones
…On Sat, Jun 4, 2022 at 11:10 PM ReBarsotti ***@***.***> wrote:
Richard,
Using a subset of the files you directed me to above, I get a timing
distribution that seems to match your plots.
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWHHEX4RC725HTDA6U3VNQLCLANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Rebecca: can you post the plot here for reference?
Is it a correct statement that the noise simulations in the two MC's (Richard's and the production MC) is significantly different?
Matt
… On Jun 5, 2022, at 8:44 PM, Richard Jones ***@***.***> wrote:
What conclusions can we draw from this? Are there still outstanding
features in the fcal timing real data distribution that simulation is
missing?
-Richard Jones
On Sat, Jun 4, 2022 at 11:10 PM ReBarsotti ***@***.***> wrote:
> Richard,
> Using a subset of the files you directed me to above, I get a timing
> distribution that seems to match your plots.
>
> —
> Reply to this email directly, view it on GitHub
> <#242 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB3YKWHHEX4RC725HTDA6U3VNQLCLANCNFSM5VVR3QHQ>
> .
> 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.
|
|
Hi Rebecca, can you let me know which MCwrapper project that was? I want to see if I can dig out some config files for Richard. |
|
Keep in mind, this is only a small sub-selection of the files, so the statistics are much poorer but here is the distribution I get with Richard's files. Matt - yes, I do think it is fair to say they are significantly different. The MCWrapper project was likely ID 1246 if I recall correctly |
|
I think we need more stats. I don’t know if we can concluded much from this. It seems this MC also under-populates the out of time distribution, but I can see some bins have 1 or 2 entries. This is probably just not sufficient to see what is going on.
Matt
On Jun 8, 2022, at 7:06 PM, ReBarsotti ***@***.***> wrote:
Keep in mind, this is only a small sub-selection of the files, so the statistics are much poorer but here is the distribution I get with Richard's files.
Matt - yes, I do think it is fair to say they are significantly different.
The MCWrapper project was likely ID 1246 if I recall correctly
[lowStatEx]<https://user-images.githubusercontent.com/40772859/172731978-5434910c-b962-429d-ab20-2658672abac6.png>
.
—
Reply to this email directly, view it on GitHub<#242 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADG5L2A3TC4ZQJUG3T2EO4TVOERMZANCNFSM5VVR3QHQ>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Can you show the results for the full statistics of the MC sample I
provided?
-Richard J.
On Wed, Jun 8, 2022 at 8:43 PM Matthew Shepherd ***@***.***>
wrote:
…
I think we need more stats. I don’t know if we can concluded much from
this. It seems this MC also under-populates the out of time distribution,
but I can see some bins have 1 or 2 entries. This is probably just not
sufficient to see what is going on.
Matt
On Jun 8, 2022, at 7:06 PM, ReBarsotti ***@***.***> wrote:
Keep in mind, this is only a small sub-selection of the files, so the
statistics are much poorer but here is the distribution I get with
Richard's files.
Matt - yes, I do think it is fair to say they are significantly different.
The MCWrapper project was likely ID 1246 if I recall correctly
[lowStatEx]<
https://user-images.githubusercontent.com/40772859/172731978-5434910c-b962-429d-ab20-2658672abac6.png>
.
—
Reply to this email directly, view it on GitHub<
#242 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ADG5L2A3TC4ZQJUG3T2EO4TVOERMZANCNFSM5VVR3QHQ>.
You are receiving this because you commented.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWFQLU2YMDMMJRTIC7DVOE4ZVANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Funnily enough, I cannot access the files from JLab as the JLab firewall prevents it. I will process the remaining files after my shift and post full plots. |
|
So this isn't _whole _ data set, as some of the files appear to have some issue have transferring them and throw errors when I try to process them, but this is a considerably larger portion of the files
|
|
Can you remind us which 4 plots above we should be comparing to? I thought it would be the first set of 4 at the very top of the thread, but it appears the at the number of data events has changed and I don't understand why. You have only been modifying the MC right? Maybe you can paste below what you get by running the exact same macro/code but using the original MC set. Then we can compare those 4 plots with the 4 plots immediately above. |
|
Hello Rebecca,
Can you send me a transcript of the copy command that is failing, together
with the error you are seeing during transfer of the files that are missing?
Also, when you make these comparative plots, would it make sense to
normalize them to the same number of events in each plot? You may need to
let the plot chop off the top of the MC peak (too sharp) but then we would
have an idea of the relative magnitude of the tails in MC and real data.
…-Richard Jones
On Wed, Jun 15, 2022 at 11:12 AM ReBarsotti ***@***.***> wrote:
So this isn't _whole _ data set, as some of the files appear to have some
issue have transferring them and throw errors when I try to process them,
but this is a considerably larger portion of the files
[image: Screen Shot 2022-06-15 at 11 09 55 AM]
<https://user-images.githubusercontent.com/40772859/173862512-e81396f0-27a2-4725-b033-cbbb7c290792.png>
—
Reply to this email directly, view it on GitHub
<#242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWFHRF6P2YCTWHABVTLVPHXGXANCNFSM5VVR3QHQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Matt- Note: The plots as they are now are normalized to both have an integral of 1.0 Richard - I receive the error message: This only occurs for some of the files though, others run with no problem
|
|
Richard -- what was the config file and settings you used to generate your MC? |
|
You will find my control.in file here in the config.d directory with other configs used for this MC set I shared with you. Here is a link to the scripts which contain other details from the run, like the ccdb variation, plugins and thread count, etc. |
|
Rebecca, I ran a complete scan over all 1000 files in my test10M_xxx_smeared.hddm set on my xrootd server and all of them have valid headers. Can you try to fetch the corrupted ones again? You may have had a timeout during the original copy. -Richard |
|
OK, when I compare this plot to the first plot in the thread, I see that the population of the tails with respect to the core in MC is significantly different.
MC experts: how do we trace the cause of this? Evidently there is a knob somewhere that is altering the amount of hits in the timing tails. We should identify that and be sure it is set appropriately.
We also need to understand why the tails are symmetric in MC but not in data. In data, I assume the origin of this was having an early hit that makes the FADC blind to the later hit. Perhaps we can mock up a similar algorithm in MC. If I recall correctly from scope traces, it takes a very long time (much longer than a pulse) for the level to return the baseline prior to a pulse. We should be able to see this with raw mode FADC data. Maybe MC is allowing the FADC to recover too quickly.
Matt
… On Jun 15, 2022, at 12:50 PM, ReBarsotti ***@***.***> wrote:
Matt-
the difference between this and the first plot in the thread is that this is only for true photon showers (instead of all hits in the detector). This makes the comparable to the plots I posted on May 21 with different hit numbers and energy ranges. Below is the plots for all hits in the detector (comparable to the first plot).
Note: The plots as they are now are normalized to both have an integral of 1.0
Richard -
I see no error message when the files are transferred. However in attempting to run the plugin:
"hd_root -PNTHREADS=16 -PPLUGINS=ShowerShapeTree test10M_889_smeared.hddm -o test.root"
I receive the error message:
"JANA >>Opening source
"test10M_889_smeared.hddm" of type: HDDM
terminate called after throwing an instance of 'std::runtime_error'
what(): hddm_s::istream::istream error - invalid hddm header
Abort (core dumped)"
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
|
Matt, do they show up here?
https://docs.google.com/document/d/1sYyH1xCi02prCK2A7_Csjqx8kZztwVooWhXLLDCOwbQ/edit?usp=sharing
-Richard Jones
…On Fri, May 27, 2022 at 8:13 AM Richard Jones ***@***.***> wrote:
Rebecca,
Here is my first attempt to reproduce plots similar to what you show,
except using bggen simulation. Here I am taking a combo of every fcal hit
with every tag, so no cuts have been applied except that something in the
event passed the physics trigger. Without any cuts, the association with
the true tag is very weak, so this is just a starting point. My next step
would be to require a recoil proton and make some sort of total energy cut,
to start moving toward a final state selection like what you are doing. If
you could share the plugin + switches you use to produce the FCal timing
distributions you showed, that would make this process go a lot faster.
-Richard
[image: image.png]
[image: image.png]
[image: image.png]
[image: image.png]
On Thu, May 26, 2022 at 9:27 AM Richard Jones ***@***.***> wrote:
> Rebecca is plotting delta t for all hits (not just those in showers) in
>> the context of these events where beam photon of interest is known with
>> good probability. The data suggest some hits come from neighboring beam
>> bunches, which is not surprising. What is surprising, as you note, is that
>> MC strongly under-predicts the number of out-of-time hits.
>>
>
> Ok, this is important, thanks. I am looking into it now.
> -Richard J.
>
> On Thu, May 26, 2022 at 9:22 AM Matthew Shepherd <
> ***@***.***> wrote:
>
>>
>> Richard,
>>
>> Yes, I agree with your assessment.
>>
>> Another point of information (which doesn't contradict anything you
>> say): Rebecca is plotting delta t for all hits (not just those in showers)
>> in the context of these events where beam photon of interest is known with
>> good probability. The data suggest some hits come from neighboring beam
>> bunches, which is not surprising. What is surprising, as you note, is that
>> MC strongly under-predicts the number of out-of-time hits.
>>
>> The root of this investigation is trying to understand why MC doesn't
>> replicate efficiency loss in beam region. The hypothesis is that out of
>> time hits might affect clustering. This led us to look at the time
>> distribution of all hits (not just those in the shower).
>>
>> Matt
>>
>>
>> > On May 25, 2022, at 2:16 PM, Richard Jones ***@***.***> wrote:
>> >
>> >
>> > Matt, understood. That is the same situation in the real data, but my
>> > interpretation of the out-of-time peaks in the FCAL time - RF time
>> > histograms for real data is that sometimes even with all of those
>> > constraints, the photons in FCAL showers come from a different beam
>> bucket
>> > than the one identified by the candidate tag photon. Not so in the MC,
>> even
>> > though Rebecca shows pretty large statistics, there is no evidence of
>> ever
>> > seeing FCAL hits in time with a different beam bucket than the one
>> chosen
>> > as the candidate tag. This does not look like what I remember seeing
>> for
>> > the same situation when I initially examined the FCAL simulation
>> output. It
>> > looks to me like a bug has crept in at some point since I first
>> examined
>> > these time spectra.
>> >
>> > -Richard Jones
>> >
>> > On Wed, May 25, 2022 at 1:55 PM Matthew Shepherd ***@***.***>
>> > wrote:
>> >
>> > >
>> > > I'm not sure if it is relevant, but Rebecca is working with exclusive
>> > > omega events. These have a tight chi^2 cut on the kinematic fit and
>> only
>> > > have one candidate beam photon. We are then looking at all FCAL hits
>> in the
>> > > context of these events where we have a good idea of what the beam
>> photon
>> > > is. This is used as the RF time for the delta T plots.
>> > >
>> > > Matt
>> > >
>> > >
>> > > > On May 25, 2022, at 12:58 PM, Richard Jones ***@***.***> wrote:
>> > > >
>> > > >
>> > > > Before I go too far out on a limb with claims of how the simulation
>> > > > behaves, let me make some plots of FCAL hit time - RF time myself
>> and
>> > > check
>> > > > that I see the picket fence that I claim should be there. There
>> might be
>> > > a
>> > > > bug in hdgeant4.
>> > > > -Richard Jones
>> > > >
>> > > > On Wed, May 25, 2022 at 10:39 AM Richard Jones ***@***.***> wrote:
>> > > >
>> > > > > Also, I think you are just plotting the calibrated FCAL times,
>> right?
>> > > So
>> > > > >> there's no reference to the beam photon in any of these plots.
>> > > > >>
>> > > > >
>> > > > > This is not true. Without the beam photon you don't know which RF
>> > > bucket
>> > > > > to take, every 4 ns.
>> > > > > -Richard Jones
>> > > > >
>> > > > > On Wed, May 25, 2022 at 10:34 AM Sean Dobbs ***@***.***>
>> > > > > wrote:
>> > > > >
>> > > > >> In that case, these were reconstructed using the reaction
>> option in
>> > > the
>> > > > >> MC Submit Form for OSG -- so standard reconstruction. Unless
>> these are
>> > > > >> default flags, there is no reason they would have been used.
>> > > > >>
>> > > > >> Also, I think you are just plotting the calibrated FCAL times,
>> right?
>> > > So
>> > > > >> there's no reference to the beam photon in any of these plots.
>> > > > >>
>> > > > >> —
>> > > > >> Reply to this email directly, view it on GitHub
>> > > > >> <
>> > >
>> #242 (comment)
>> > > >,
>> > > > >> or unsubscribe
>> > > > >> <
>> > >
>> https://github.com/notifications/unsubscribe-auth/AB3YKWEGM2KPWHA73PKEJTDVLY3ADANCNFSM5VVR3QHQ
>> > > >
>> > > > >> .
>> > > > >> 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/AB3YKWDHYC4JTUTA3STDQL3VLZSPPANCNFSM5VVR3QHQ
>> >
>> > > .
>> > > 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/AB3YKWE7KOOHPJNBBASJSXDVL53KVANCNFSM5VVR3QHQ>
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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!
The text was updated successfully, but these errors were encountered: