Inconsistently counted beam photon in reconstructed MC/thrown MC at beam energies where TAGH and TAGM overlaps #850
Comments
|
Hao,
The doubling of the tags in these overlap regions would indeed produce a
doubling of the apparent reconstruction efficiency in these regions, as you
describe. Is a similar coincidence seen in the real data at the two ends of
the microscope? Here are some pictures from the tagger simulation of an
electron with energy close to the center of the first TAGM column
1. zoomed out, showing the rays through the entire focal plane array
2. zoomed in on TAGM fiber column 1
3. zoomed in on TAGH counter 128
4. zoomed in on TAGH counter 126 (this counter is not installed for some
run periods)
5. zoomed in on TAGH counter 127
Multiple scattering means that the alignment is not perfect in real life,
as the pseudo-tags pretend that it is. Still there should be some enhanced
reconstruction "efficiency" in this region for real data.
…-Richard
On Tue, Oct 29, 2024 at 2:39 AM Hao Li ***@***.***> wrote:
What happened?
This is another subtle issue that differs a bit from the already resolved
issue #810 <#810>
(which create a dip in the reconstructed efficiency). Instead, it results
in spike-like structure in the reconstructed efficiency at around beam
energy of 8.9 GeV where the tagger hodoscope TAGH#127 overlaps almost
entirely with microscope column TAGM#1. Specific beam energies may differ
according to different electron beam energy from run to run and different
tagger energy scale from run period to run period, but similar spike
structure is seen in both ppbar and lamlambar channel reconstruction
efficiencies from all run periods in GlueX Phase-I:
Screenshot.2024-10-29.at.01.33.59.png (view on web)
<https://github.com/user-attachments/assets/f5477191-6928-4112-a169-37b7ed11f7c2>Screenshot.2024-10-29.at.01.34.09.png
(view on web)
<https://github.com/user-attachments/assets/9e5278a5-6148-42cd-85d5-b1d04cb99917>
How to reproduce the issue and what is the cause?
Further investigation is done using ppbar MC for a single run 30496 from
sp17, and no random triggers. The simulation is done using version set
5.21.0. And the beam energy is set to be between 8.880-8.890 GeV. The REST
files shows that for each event, the generated beamPhoton is registered as
signal in both TAGM#1 and TAGH#127, while the thrown information remains to
be only hits at TAGM#1:
Event: 1
DBeamPhoton:
E(GeV): System: Counter: t(ns):
----------------------------------
8.884361 TAGM 1 -4.0
8.888765 TAGH 127 -3.6
DBeamPhoton:TAGGEDMCGEN
E(GeV): System: Counter: t(ns):
----------------------------------
8.884361 TAGM 1 -4.0
and the reconstructed efficiency at this range is estimated to be twice
higher than the neighboring bin:
Screenshot.2024-10-29.at.01.54.29.png (view on web)
<https://github.com/user-attachments/assets/d9820d04-d077-40ba-ad9c-a81325b673da>
(blue is MC with beam energy range 8.88-8.89 GeV, and red is another MC
with beam energy range 8.88-8.90 GeV including the neighboring bin whose
efficiency is normal).
The cause seems to be that for each DBeamPhoton:TAGGEDMCGEN that goes into
the mcthrown tree, there are twice number of reconstructed photons that end
up in the numerator of the efficiency calculation. As shown in the table
above, it seems that only TAGM hit is recorded for DBeamPhoton:TAGGEDMCGEN,
which is inconsistent from the double counting in DBeamPhoton factory.
Hence the efficiency doubled at that energy range. For the entire run
period, because of the slightly fluctuating electron beam energy, it is
smeared into a spike-like structure as spotted in the plots above.
The sample rest file with 100 events, along with other HDDM files produced
during the simulation pipeline, is stored at
/w/halld-scshelf2101/home/haoli/test/spike_test/8.880-8.890/hddm.
Which part of the HallD code is relevant?
The double-counted beam photon seems to originated from the Pseudo tagger
in HDGeant4
<https://github.com/JeffersonLab/HDGeant4/blob/master/src/GlueXPseudoDetectorTAG.cc#L305>
where it allows beam photon to be detected by both hodoscope and microscope
respectively. However it might create broader impact if we don't allow beam
photon to be detected by both TAGH and TAGM.
Another option might be allow double-counting beam photon in the thrown
tree so that the effect cancels out in both numerator and denominator of
the reconstructed efficiency calculation.
Where else is affected?
Beside the largely overlapped TAGH#127 and TAGM#1, there is also a small
overlapping between TAGH#179 and TAGM#102. Double-counted reconstructed
beam photon can also be seen:
Event: 49
DBeamPhoton:
E(GeV): System: Counter: t(ns):
----------------------------------
7.898822 TAGM 102 -0.2
7.856271 TAGH 179 -0.3
DBeamPhoton:TAGGEDMCGEN
E(GeV): System: Counter: t(ns):
----------------------------------
7.898822 TAGM 102 -0.2
what is weirder is that here the two tagger are quite apart from each
other. The simulation here is generated with beam energy range 7.860-7.870
GeV. (HDDM file sample at
/w/halld-scshelf2101/home/haoli/test/spike_test/7.860-7.870/hddm)
—
Reply to this email directly, view it on GitHub
<#850>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWHYZFZSA4BGYOYFCATZ54USVAVCNFSM6AAAAABQZDUM2GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZDAMRYGA4DEOI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
PS. Correction -- I think it is counter 128 that is not installed for some
run periods, 126 should be there.
-Richard Jones
…On Tue, Oct 29, 2024 at 7:26 AM Richard Jones ***@***.***> wrote:
Hao,
The doubling of the tags in these overlap regions would indeed produce a
doubling of the apparent reconstruction efficiency in these regions, as you
describe. Is a similar coincidence seen in the real data at the two ends of
the microscope? Here are some pictures from the tagger simulation of an
electron with energy close to the center of the first TAGM column
1. zoomed out, showing the rays through the entire focal plane array
2. zoomed in on TAGM fiber column 1
3. zoomed in on TAGH counter 128
4. zoomed in on TAGH counter 126 (this counter is not installed for
some run periods)
5. zoomed in on TAGH counter 127
Multiple scattering means that the alignment is not perfect in real life,
as the pseudo-tags pretend that it is. Still there should be some enhanced
reconstruction "efficiency" in this region for real data.
-Richard
On Tue, Oct 29, 2024 at 2:39 AM Hao Li ***@***.***> wrote:
> What happened?
>
> This is another subtle issue that differs a bit from the already resolved
> issue #810 <#810>
> (which create a dip in the reconstructed efficiency). Instead, it results
> in spike-like structure in the reconstructed efficiency at around beam
> energy of 8.9 GeV where the tagger hodoscope TAGH#127 overlaps almost
> entirely with microscope column TAGM#1. Specific beam energies may differ
> according to different electron beam energy from run to run and different
> tagger energy scale from run period to run period, but similar spike
> structure is seen in both ppbar and lamlambar channel reconstruction
> efficiencies from all run periods in GlueX Phase-I:
> Screenshot.2024-10-29.at.01.33.59.png (view on web)
> <https://github.com/user-attachments/assets/f5477191-6928-4112-a169-37b7ed11f7c2>Screenshot.2024-10-29.at.01.34.09.png
> (view on web)
> <https://github.com/user-attachments/assets/9e5278a5-6148-42cd-85d5-b1d04cb99917>
> How to reproduce the issue and what is the cause?
>
> Further investigation is done using ppbar MC for a single run 30496 from
> sp17, and no random triggers. The simulation is done using version set
> 5.21.0. And the beam energy is set to be between 8.880-8.890 GeV. The REST
> files shows that for each event, the generated beamPhoton is registered as
> signal in both TAGM#1 and TAGH#127, while the thrown information remains to
> be only hits at TAGM#1:
>
> Event: 1
> DBeamPhoton:
> E(GeV): System: Counter: t(ns):
> ----------------------------------
> 8.884361 TAGM 1 -4.0
> 8.888765 TAGH 127 -3.6
>
> DBeamPhoton:TAGGEDMCGEN
> E(GeV): System: Counter: t(ns):
> ----------------------------------
> 8.884361 TAGM 1 -4.0
>
> and the reconstructed efficiency at this range is estimated to be twice
> higher than the neighboring bin:
> Screenshot.2024-10-29.at.01.54.29.png (view on web)
> <https://github.com/user-attachments/assets/d9820d04-d077-40ba-ad9c-a81325b673da>
> (blue is MC with beam energy range 8.88-8.89 GeV, and red is another MC
> with beam energy range 8.88-8.90 GeV including the neighboring bin whose
> efficiency is normal).
>
> The cause seems to be that for each DBeamPhoton:TAGGEDMCGEN that goes
> into the mcthrown tree, there are twice number of reconstructed photons
> that end up in the numerator of the efficiency calculation. As shown in the
> table above, it seems that only TAGM hit is recorded for
> DBeamPhoton:TAGGEDMCGEN, which is inconsistent from the double counting in
> DBeamPhoton factory. Hence the efficiency doubled at that energy range. For
> the entire run period, because of the slightly fluctuating electron beam
> energy, it is smeared into a spike-like structure as spotted in the plots
> above.
>
> The sample rest file with 100 events, along with other HDDM files
> produced during the simulation pipeline, is stored at
> /w/halld-scshelf2101/home/haoli/test/spike_test/8.880-8.890/hddm.
> Which part of the HallD code is relevant?
>
> The double-counted beam photon seems to originated from the Pseudo
> tagger in HDGeant4
> <https://github.com/JeffersonLab/HDGeant4/blob/master/src/GlueXPseudoDetectorTAG.cc#L305>
> where it allows beam photon to be detected by both hodoscope and microscope
> respectively. However it might create broader impact if we don't allow beam
> photon to be detected by both TAGH and TAGM.
>
> Another option might be allow double-counting beam photon in the thrown
> tree so that the effect cancels out in both numerator and denominator of
> the reconstructed efficiency calculation.
> Where else is affected?
>
> Beside the largely overlapped TAGH#127 and TAGM#1, there is also a small
> overlapping between TAGH#179 and TAGM#102. Double-counted reconstructed
> beam photon can also be seen:
>
> Event: 49
> DBeamPhoton:
> E(GeV): System: Counter: t(ns):
> ----------------------------------
> 7.898822 TAGM 102 -0.2
> 7.856271 TAGH 179 -0.3
>
> DBeamPhoton:TAGGEDMCGEN
> E(GeV): System: Counter: t(ns):
> ----------------------------------
> 7.898822 TAGM 102 -0.2
>
> what is weirder is that here the two tagger are quite apart from each
> other. The simulation here is generated with beam energy range 7.860-7.870
> GeV. (HDDM file sample at
> /w/halld-scshelf2101/home/haoli/test/spike_test/7.860-7.870/hddm)
>
> —
> Reply to this email directly, view it on GitHub
> <#850>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB3YKWHYZFZSA4BGYOYFCATZ54USVAVCNFSM6AAAAABQZDUM2GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZDAMRYGA4DEOI>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
|
@rjones30 Hi Richard, the pictures are not shown up in your replies. |
|
It appears that the double counting is consistent in both raw yield and
the tagged flux, so no spikes shown up.
Aha, ok. So what we want in the simulation is to do the same thing: divide
the MC raw yield by the MC tagged flux. Then these spikes should disappear,
right?
…-Richard Jones
On Tue, Oct 29, 2024 at 11:09 AM Hao Li ***@***.***> wrote:
@rjones30 <https://github.com/rjones30> Hi Richard, the pictures are not
shown up in your replies.
In real data (flux normalized), it is smooth in the transition area
between TAGH and TAGM:
Screenshot.2024-10-29.at.11.07.49.png (view on web)
<https://github.com/user-attachments/assets/7a247f72-4d3e-4b07-9306-cdc952d48347>
It appears that the double counting is consistent in both raw yield and
the tagged flux, so no spikes shown up.
—
Reply to this email directly, view it on GitHub
<#850 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWB6BI4AV3EGZ4UUNH3Z56QKNAVCNFSM6AAAAABQZDUM2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGU2TAMBRHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
This issue will become central for the CPP data set, where there is a large overlap between TagM and TagH. Are you suggesting to duplicate events in data and MC when the photon can hit both detectors? |
|
Are you suggesting to duplicate events in data and MC when the photon can
hit both detectors?
In the tagm right now we have a clustering algorithm that reduces multiple
hits from a single tag electron across adjacent counters. There is a
similar algorithm applied to adjacent counters in the tagh, which is
somewhat worse because of the stagger in the focal plane geometry. To
reduce these mixed tagh + tagm clusters we could modify our clustering
algorithm to cluster between the tagm+tagh in the overlap region, or we
could just let the simulation duplicate the "split tags" and account for it
that way.
…-Richard
On Tue, Oct 29, 2024 at 2:30 PM Alexander Austregesilo < ***@***.***> wrote:
This issue will become central for the CPP data set, where there is a
large overlap between TagM and TagH. Are you suggesting to duplicate events
in data and MC when the photon can hit both detectors?
—
Reply to this email directly, view it on GitHub
<#850 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3YKWER4V2MOQMB6DRN7P3Z57H2VAVCNFSM6AAAAABQZDUM2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBVGA2DEMRRGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@rjones30 Hi Richard, I missed the Beamline meeting this week, has there been any discussion about this github issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
This is another subtle issue that differs a bit from the already resolved issue #810 (which create a dip in the reconstructed efficiency). Instead, it results in spike-like structure in the reconstructed efficiency at around beam energy of 8.9 GeV where the tagger hodoscope TAGH#127 overlaps almost entirely with microscope column TAGM#1. Specific beam energies may differ according to different electron beam energy from run to run and different tagger energy scale from run period to run period, but similar spike structure is seen in both ppbar and lamlambar channel reconstruction efficiencies from all run periods in GlueX Phase-I:
How to reproduce the issue and what is the cause?
Further investigation is done using ppbar MC for a single run 30496 from sp17, and no random triggers. The simulation is done using version set 5.21.0. And the beam energy is set to be between 8.880-8.890 GeV. The REST files shows that for each event, the generated beamPhoton is registered as signal in both TAGM#1 and TAGH#127, while the thrown information remains to be only hits at TAGM#1:
and the reconstructed efficiency at this range is estimated to be twice higher than the neighboring bin:
(blue is MC with beam energy range 8.88-8.89 GeV, and red is another MC with beam energy range 8.88-8.90 GeV including the neighboring bin whose efficiency is normal).
The cause seems to be that for each DBeamPhoton:TAGGEDMCGEN that goes into the mcthrown tree, there are twice number of reconstructed photons that end up in the numerator of the efficiency calculation. As shown in the table above, it seems that only TAGM hit is recorded for DBeamPhoton:TAGGEDMCGEN, which is inconsistent from the double counting in DBeamPhoton factory. Hence the efficiency doubled at that energy range. For the entire run period, because of the slightly fluctuating electron beam energy, it is smeared into a spike-like structure as spotted in the plots above.
The sample rest file with 100 events, along with other HDDM files produced during the simulation pipeline, is stored at
/w/halld-scshelf2101/home/haoli/test/spike_test/8.880-8.890/hddm.Which part of the HallD code is relevant?
The double-counted beam photon seems to originated from the Pseudo tagger in HDGeant4 where it allows beam photon to be detected by both hodoscope and microscope respectively. However it might create broader impact if we don't allow beam photon to be detected by both TAGH and TAGM.
Another option might be allow double-counting beam photon in the thrown tree so that the effect cancels out in both numerator and denominator of the reconstructed efficiency calculation.
Where else is affected?
Beside the largely overlapped TAGH#127 and TAGM#1, there is also a small overlapping between TAGH#179 and TAGM#102. Double-counted reconstructed beam photon can also be seen:
what is weirder is that here the two tagger are quite apart from each other. The simulation here is generated with beam energy range 7.860-7.870 GeV. (HDDM file sample at
/w/halld-scshelf2101/home/haoli/test/spike_test/7.860-7.870/hddm)The text was updated successfully, but these errors were encountered: