JeffersonLab / HDGeant4

Geant4 simulation for the GlueX experiment
4 stars 4 forks source link

hits in both CALs from the same track #185

Closed pentchev closed 3 years ago

pentchev commented 3 years ago

I'm doing MC with both g3 and g4, of the BH reaction with e+e-p in the final state and look at the trees out of the Reaction Filter. To make things easier to explain, this plot was made by such commands:

epemB3_Tree->Draw("Positron__P4_KinFit.Theta()*57.3","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypoEnergy_FCAL[Positron__ChargedIndex]>0&&abs(RFTime_Measured-ThrownBeam__X4.T())<2.")

I don't know what is the criteria to assign hits in the calorimeter(s) to a certain track, but if I look at the other two tracks with the same cuts, their azimuthal angles are very different, so the hits in the two calorimeters are coming from the same track. Also these are not randoms, as there are no such events out of the prompt peak, so the timing selection is not needed.

I see two issues here. There is a difference between the two geants when propagating e.m. showers through the calorimeters. When the electron/positron hits the edge of BCAL (at ~10deg) certainly some photons can escape and hit FCAL, which I see in g3 but not in g4.

As for the two camel humps at theta>10 deg, the problem is mots likely somewhere in the tracking/analysis as it is present in both geants and the energy deposited in the calorimeters doesn't make sense.

Note that in my case, these events represent ~0.1% of all the simulated events.

rjones30 commented 3 years ago

Hello Lubomir,

There is an issue in G3 (hdgeant) where the same track number can be assigned to multiple tracks in a given shower if they happen one after another from the same particle. For example, if an electron radiates a photon and stops in the same step, then the photon can carry on with the same track number as the parent particle. Then that photon can undergo the photoelectric effect and stop, leaving an excited electron that then carries on with the same track id. This is an artifact of the way G3 keeps track of secondaries, and is not present in G4. Might that explain what you are seeing, or are you not using the track number recorded in the simulation output?

-Richard Jones

On Wed, Mar 3, 2021 at 4:40 PM pentchev notifications@github.com wrote:

I'm doing MC with both g3 and g4, of the BH reaction with e+e-p in the final state and look at the trees out of the Reaction Filter. To make things easier to explain, http://www.jlab.org/Hall-D/detector/fdc/Mar21_analysis_g34comp.pdf this plot http://url was made by such commands:

epemB3_Tree->Draw("Positron__P4_KinFit.Theta()*57.3","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypoEnergy_FCAL[Positron__ChargedIndex]>0&&abs(RFTime_Measured-ThrownBeam__X4.T())<2.")

I don't know what is the criteria to assign hits in the calorimeter(s) to a certain track, but if I look at the other two tracks with the same cuts, their azimuthal angles are very different, so the hits in the two calorimeters are coming from the same track. Also these are not randoms, as there are no such events out of the prompt peak, so the timing selection is not needed.

I see two issues here. There is a difference between the two geants when propagating e.m. showers through the calorimeters. When the electron/positron hits the edge of BCAL (at ~10deg) certainly some photons can escape and hit FCAL, which I see in g3 but not in g4.

As for the two camel humps at theta>10 deg, the problem is mots likely somewhere in the tracking/analysis as it is present in both geants and the energy deposited in the calorimeters doesn't make sense.

Note that in my case, these events represent ~0.1% of all the simulated events.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWFPA2Y6Z5W4BNGWXMDTB2UDBANCNFSM4YSAUSUA .

pentchev commented 3 years ago

Hi Richard,

Thanks for your response. The symptoms I see are at the final level of the analysis. I don't know if the track id is used in the analysis. First, I need to understand how the calorimeter hits are assigned to a certain track, by the track id or probably by the proximity of the track trajectory to the hit position? In any case it is important to have in mind the issue with G3 that you explained.

Lubomir


From: Richard Jones notifications@github.com Sent: Wednesday, March 3, 2021 6:26 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author author@noreply.github.com Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

Hello Lubomir,

There is an issue in G3 (hdgeant) where the same track number can be assigned to multiple tracks in a given shower if they happen one after another from the same particle. For example, if an electron radiates a photon and stops in the same step, then the photon can carry on with the same track number as the parent particle. Then that photon can undergo the photoelectric effect and stop, leaving an excited electron that then carries on with the same track id. This is an artifact of the way G3 keeps track of secondaries, and is not present in G4. Might that explain what you are seeing, or are you not using the track number recorded in the simulation output?

-Richard Jones

On Wed, Mar 3, 2021 at 4:40 PM pentchev notifications@github.com wrote:

I'm doing MC with both g3 and g4, of the BH reaction with e+e-p in the final state and look at the trees out of the Reaction Filter. To make things easier to explain, http://www.jlab.org/Hall-D/detector/fdc/Mar21_analysis_g34comp.pdf this plot http://url was made by such commands:

epemB3_Tree->Draw("Positron__P4_KinFit.Theta()*57.3","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypoEnergy_FCAL[Positron__ChargedIndex]>0&&abs(RFTime_Measured-ThrownBeam__X4.T())<2.")

I don't know what is the criteria to assign hits in the calorimeter(s) to a certain track, but if I look at the other two tracks with the same cuts, their azimuthal angles are very different, so the hits in the two calorimeters are coming from the same track. Also these are not randoms, as there are no such events out of the prompt peak, so the timing selection is not needed.

I see two issues here. There is a difference between the two geants when propagating e.m. showers through the calorimeters. When the electron/positron hits the edge of BCAL (at ~10deg) certainly some photons can escape and hit FCAL, which I see in g3 but not in g4.

As for the two camel humps at theta>10 deg, the problem is mots likely somewhere in the tracking/analysis as it is present in both geants and the energy deposited in the calorimeters doesn't make sense.

Note that in my case, these events represent ~0.1% of all the simulated events.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWFPA2Y6Z5W4BNGWXMDTB2UDBANCNFSM4YSAUSUA .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D790147170&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=TWAe3K2om9CdE0X2tFaZaImakWJIAAY8cdAEJvIRhHk&s=hPHvUlPV1ggf_U55rfkB5LLB3tvMru3PqgpoDXPfHuE&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6RR4JA4QFGWOVNT3XDTB3ARNANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=TWAe3K2om9CdE0X2tFaZaImakWJIAAY8cdAEJvIRhHk&s=3J2N78v6Iz-3pSfQsIyZu75BJIde9pZlfElYWRaYBjY&e=.

rjones30 commented 3 years ago

In your last message, you wrote:

I don't know if the track id is used in the analysis. First, I need to understand how the calorimeter hits are assigned to a certain track, by the track id or probably by the proximity of the track trajectory to the hit position?

Calorimeter hits are not assigned to a certain track, as far as I can see. Look at libraries/FCAL/DFCALHit.h and libraries/BCAL/DBCALHit.h. There is no information in there that identifies a particular track that associates to the hit.

There is an object called DFCALTruthShower. That object is not a hit and does not contain any hits. It is MC truth information and is not used in the regular analysis. It is only there in case you want to check what the Monte Carlo actually saw entering the calorimeter, so you can compare it to the calorimeter response. This DFCALTruthShower has an element "track" that is that track id that I was talking about in my last message. That track id can sometimes be reused by multiple sequential particles in a shower in G3, but not in G4.

-Richard Jones

On Wed, Mar 3, 2021 at 11:01 PM pentchev notifications@github.com wrote:

Hi Richard,

Thanks for your response. The symptoms I see are at the final level of the analysis. I don't know if the track id is used in the analysis. First, I need to understand how the calorimeter hits are assigned to a certain track, by the track id or probably by the proximity of the track trajectory to the hit position? In any case it is important to have in mind the issue with G3 that you explained.

Lubomir


From: Richard Jones notifications@github.com Sent: Wednesday, March 3, 2021 6:26 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author < author@noreply.github.com> Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

Hello Lubomir,

There is an issue in G3 (hdgeant) where the same track number can be assigned to multiple tracks in a given shower if they happen one after another from the same particle. For example, if an electron radiates a photon and stops in the same step, then the photon can carry on with the same track number as the parent particle. Then that photon can undergo the photoelectric effect and stop, leaving an excited electron that then carries on with the same track id. This is an artifact of the way G3 keeps track of secondaries, and is not present in G4. Might that explain what you are seeing, or are you not using the track number recorded in the simulation output?

-Richard Jones

On Wed, Mar 3, 2021 at 4:40 PM pentchev notifications@github.com wrote:

I'm doing MC with both g3 and g4, of the BH reaction with e+e-p in the final state and look at the trees out of the Reaction Filter. To make things easier to explain, http://www.jlab.org/Hall-D/detector/fdc/Mar21_analysis_g34comp.pdf this plot http://url was made by such commands:

epemB3_Tree->Draw("Positron__P4_KinFit.Theta()*57.3","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypoEnergy_FCAL[Positron__ChargedIndex]>0&&abs(RFTime_Measured-ThrownBeam__X4.T())<2.")

I don't know what is the criteria to assign hits in the calorimeter(s) to a certain track, but if I look at the other two tracks with the same cuts, their azimuthal angles are very different, so the hits in the two calorimeters are coming from the same track. Also these are not randoms, as there are no such events out of the prompt peak, so the timing selection is not needed.

I see two issues here. There is a difference between the two geants when propagating e.m. showers through the calorimeters. When the electron/positron hits the edge of BCAL (at ~10deg) certainly some photons can escape and hit FCAL, which I see in g3 but not in g4.

As for the two camel humps at theta>10 deg, the problem is mots likely somewhere in the tracking/analysis as it is present in both geants and the energy deposited in the calorimeters doesn't make sense.

Note that in my case, these events represent ~0.1% of all the simulated events.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB3YKWFPA2Y6Z5W4BNGWXMDTB2UDBANCNFSM4YSAUSUA

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D790147170&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=TWAe3K2om9CdE0X2tFaZaImakWJIAAY8cdAEJvIRhHk&s=hPHvUlPV1ggf_U55rfkB5LLB3tvMru3PqgpoDXPfHuE&e=>, or unsubscribe< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6RR4JA4QFGWOVNT3XDTB3ARNANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=TWAe3K2om9CdE0X2tFaZaImakWJIAAY8cdAEJvIRhHk&s=3J2N78v6Iz-3pSfQsIyZu75BJIde9pZlfElYWRaYBjY&e=

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-790271942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWCRVZZ6NSL33ULWJ5LTB4A2DANCNFSM4YSAUSUA .

zihlmann commented 3 years ago

Hi Lubmoir, I do not think that is how the algorithm works, or there is some misunderstanding. There will be "showers" assigned to a charged track, never individual calorimeter hits. The reconstruction, independently of tracking, will construct showers in the calorimeters based on hits in the individual readout channels (block in the FCAL, Regions in the BCAL). By readout channel I mean an ADC channel. This will lead to a list of showers and then this list is searched by a matching step to search for a shower that matches a given track. Note that the shower position is determined by a convoluted average of the calorimeter hits that contribute to that shower.

cheers, Beni

On 3/3/21 11:01 PM, pentchev wrote:

Hi Richard,

Thanks for your response. The symptoms I see are at the final level of the analysis. I don't know if the track id is used in the analysis. First, I need to understand how the calorimeter hits are assigned to a certain track, by the track id or probably by the proximity of the track trajectory to the hit position? In any case it is important to have in mind the issue with G3 that you explained.

Lubomir


From: Richard Jones notifications@github.com Sent: Wednesday, March 3, 2021 6:26 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author author@noreply.github.com Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

Hello Lubomir,

There is an issue in G3 (hdgeant) where the same track number can be assigned to multiple tracks in a given shower if they happen one after another from the same particle. For example, if an electron radiates a photon and stops in the same step, then the photon can carry on with the same track number as the parent particle. Then that photon can undergo the photoelectric effect and stop, leaving an excited electron that then carries on with the same track id. This is an artifact of the way G3 keeps track of secondaries, and is not present in G4. Might that explain what you are seeing, or are you not using the track number recorded in the simulation output?

-Richard Jones

On Wed, Mar 3, 2021 at 4:40 PM pentchev notifications@github.com wrote:

I'm doing MC with both g3 and g4, of the BH reaction with e+e-p in the final state and look at the trees out of the Reaction Filter. To make things easier to explain, http://www.jlab.org/Hall-D/detector/fdc/Mar21_analysis_g34comp.pdf this plot http://url was made by such commands:

epemB3_Tree->Draw("Positron__P4_KinFit.Theta()*57.3","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypoEnergy_FCAL[Positron__ChargedIndex]>0&&abs(RFTime_Measured-ThrownBeam__X4.T())<2.")

I don't know what is the criteria to assign hits in the calorimeter(s) to a certain track, but if I look at the other two tracks with the same cuts, their azimuthal angles are very different, so the hits in the two calorimeters are coming from the same track. Also these are not randoms, as there are no such events out of the prompt peak, so the timing selection is not needed.

I see two issues here. There is a difference between the two geants when propagating e.m. showers through the calorimeters. When the electron/positron hits the edge of BCAL (at ~10deg) certainly some photons can escape and hit FCAL, which I see in g3 but not in g4.

As for the two camel humps at theta>10 deg, the problem is mots likely somewhere in the tracking/analysis as it is present in both geants and the energy deposited in the calorimeters doesn't make sense.

Note that in my case, these events represent ~0.1% of all the simulated events.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185, or unsubscribe

https://github.com/notifications/unsubscribe-auth/AB3YKWFPA2Y6Z5W4BNGWXMDTB2UDBANCNFSM4YSAUSUA .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D790147170&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=TWAe3K2om9CdE0X2tFaZaImakWJIAAY8cdAEJvIRhHk&s=hPHvUlPV1ggf_U55rfkB5LLB3tvMru3PqgpoDXPfHuE&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6RR4JA4QFGWOVNT3XDTB3ARNANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=TWAe3K2om9CdE0X2tFaZaImakWJIAAY8cdAEJvIRhHk&s=3J2N78v6Iz-3pSfQsIyZu75BJIde9pZlfElYWRaYBjY&e=.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D790271942&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Hy7ijcc6pcMoP-QxZxtQH4-vodW_VGkrA9xiBc7InXk&m=m1pSy_-CL41eOr27Xh-7D1GjTJX1sIhqzKjIZ7YlyKU&s=Lhc1JeEcYBvl4XReENqVSFNdCSZmED0pZwHpRbMH4xo&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADF7ACZJDDQ2THF2UWXVD53TB4A2DANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Hy7ijcc6pcMoP-QxZxtQH4-vodW_VGkrA9xiBc7InXk&m=m1pSy_-CL41eOr27Xh-7D1GjTJX1sIhqzKjIZ7YlyKU&s=S6aIV--GNsz28_akbbF2-aYYFLYcILppzaJx7rpYTvo&e=.

sdobbs commented 3 years ago

Hi all,

So, I think there is some confusion here. This data is at the analysis ROOT tree level, where MC information is not being used, but instead calorimeter/timing detector hits are matched to tracks by projecting the tracks to the faces (generally) of the other detectors and applying some geometrical cuts (the projected track/detector hit have to be within a certain distance).

The effect near the FCAL/BCAL transition region is perhaps understandable - in doing studies for a fiducial cut in this region, Mark Dalton looked at some photon gun simulations and found that the spray out of the back end of the BCAL for showers in this region did lead to significant differences in the energy deposited in the FCAL (I can pull out a reference for those interested). This is one of the reasons why we made a fiducial cut for photon reconstruction - maybe one would be useful for electrons as well.

The distribution for larger angle tracks doesn't make any sense to me. Perhaps there's some pathology in the track/hit matching we need to understand. The information about the matched showers is saved in the ROOT tree, so it would be interesting to look at the position and energy distribution of the FCAL showers which are matched to tracks with, say, theta > 20 degrees. That could give some insight.

---Sean

pentchev commented 3 years ago

See bellow few of the events with theta >15 that I scanned. In the last six columns you have positron's FCAL, BCAL and measured momentum, and then the same for the electron. You can see the FCAL energy is EXACTLY the same for the electron and positron. Based on the momenta we can say that the positron deposited energy only in BCAL, but somehow in addition the signal in FCAL from the electron was assigned also to the positron.

root[13]epemB3_Tree->Scan("ChargedHypo__Energy_FCAL[PositronChargedIndex]:ChargedHypoEnergy_BCAL[PositronChargedIndex]:ChargedHypoP4_Measured[PositronChargedIndex].P():ChargedHypoEnergy_FCAL[ElectronChargedIndex]:ChargedHypoEnergy_BCAL[ElectronChargedIndex]:ChargedHypoP4_Measured[ElectronChargedIndex].P()","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypo__Energy_FCAL[Positron__ChargedIndex]>0")


rjones30 commented 3 years ago

Lubomir,

I wonder if you might look at what Sean wrote, and address it? Sean is saying that two things are being confused here, at least by me.

  1. associations of calorimeter clusters with tracks that are made at simulation time, and passed through the simulation Truth information recorded in the hddm record to the reconstruction and root trees;
  2. associations of calorimeter clusters with tracks that are formed during the event reconstruction, after tracks have been found and fitted, calorimeter clusters found, and a proximity test applied to the track projection onto the calorimeter surface. This association has no input from any simulation Truth information passed through the hddm record to the reconstruction and root trees.

Which of these two sources of association are you reporting here? If it is

2, I doubt I have much to offer you in terms of insight, as this is a

post-reconstruction track-cluster reconstruction issue. If the source of this association information is #1 then I may be able to contribute to the discussion.

-Richard Jones

On Sun, Mar 7, 2021 at 7:38 PM pentchev notifications@github.com wrote:

See bellow few of the events with theta >15 that I scanned. In the last six columns you have positron's FCAL, BCAL and measured momentum, and then the same for the electron. You can see the FCAL energy is EXACTLY the same for the electron and positron. Based on the momenta we can say that the positron deposited energy only in BCAL, but somehow in addition the signal in FCAL from the electron was assigned also to the positron.

root[13]epemB3_Tree->Scan("ChargedHypo__Energy_FCAL[PositronChargedIndex]:ChargedHypoEnergy_BCAL[PositronChargedIndex]:ChargedHypoP4_Measured[PositronChargedIndex].P():ChargedHypoEnergy_FCAL[ElectronChargedIndex]:ChargedHypoEnergy_BCAL[ElectronChargedIndex]:ChargedHypoP4_Measured[ElectronChargedIndex].P()","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypo__Energy_FCAL[Positron__ChargedIndex]>0")

  • Row Instance ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy

-

1279 0 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 1 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 2 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 3 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 4 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 5 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 6 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 7 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 8 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 9 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 10 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 11 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1947 0 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 1 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 2 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 3 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 4 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 5 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 6 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 7 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 8 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 9 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 10 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 11 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

3702 0 8.2515211 0.4371795 0.4544905 8.2515211 0 8.7837560

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792388981, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWGWBUCUVYH77UXEZ3TTCQMAFANCNFSM4YSAUSUA .

sdobbs commented 3 years ago

Lubomir: Thanks, could you please add the run/event numbers to these entries, along with the corresponding REST file? I feel like this must be a bug somewhere?

Richard: Indeed, these trees are at the level of your #2, but let's take a look at a couple of these simulated events, and we can see if we can give you something actionable.

---Sean

On Sun, Mar 7, 2021 at 8:11 PM Richard Jones notifications@github.com wrote:

Lubomir,

I wonder if you might look at what Sean wrote, and address it? Sean is saying that two things are being confused here, at least by me.

  1. associations of calorimeter clusters with tracks that are made at simulation time, and passed through the simulation Truth information recorded in the hddm record to the reconstruction and root trees;
  2. associations of calorimeter clusters with tracks that are formed during the event reconstruction, after tracks have been found and fitted, calorimeter clusters found, and a proximity test applied to the track projection onto the calorimeter surface. This association has no input from any simulation Truth information passed through the hddm record to the reconstruction and root trees.

Which of these two sources of association are you reporting here? If it is

2, I doubt I have much to offer you in terms of insight, as this is a

post-reconstruction track-cluster reconstruction issue. If the source of this association information is #1 then I may be able to contribute to the discussion.

-Richard Jones

On Sun, Mar 7, 2021 at 7:38 PM pentchev notifications@github.com wrote:

See bellow few of the events with theta >15 that I scanned. In the last six columns you have positron's FCAL, BCAL and measured momentum, and then the same for the electron. You can see the FCAL energy is EXACTLY the same for the electron and positron. Based on the momenta we can say that the positron deposited energy only in BCAL, but somehow in addition the signal in FCAL from the electron was assigned also to the positron.

root[13]epemB3_Tree->Scan("ChargedHypo__Energy_FCAL[PositronChargedIndex]:ChargedHypoEnergy_BCAL[PositronChargedIndex]:ChargedHypoP4_Measured[PositronChargedIndex].P():ChargedHypoEnergy_FCAL[ElectronChargedIndex]:ChargedHypoEnergy_BCAL[ElectronChargedIndex]:ChargedHypoP4_Measured[ElectronChargedIndex].P()","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypo__Energy_FCAL[Positron__ChargedIndex]>0")

  • Row Instance ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy

-

1279 0 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 1 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 2 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 3 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 4 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 5 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 6 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 7 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 8 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 9 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 10 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 11 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1947 0 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 1 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 2 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 3 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 4 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 5 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 6 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 7 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 8 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 9 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 10 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 11 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

3702 0 8.2515211 0.4371795 0.4544905 8.2515211 0 8.7837560

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792388981 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB3YKWGWBUCUVYH77UXEZ3TTCQMAFANCNFSM4YSAUSUA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792397533, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJAS2QJ4BHPIXDXGSNQU2DTCQP5LANCNFSM4YSAUSUA .

pentchev commented 3 years ago

Richard,

In my last comment, for events with theta>15deg, I meant track-shower associations as in #2, i.e. during the event reconstruction and there's obviously a bug there.

However, the other group of events with theta<15 deg is present only in g3 but not in g4. That is why I assume that some differences in the simulations cause this issue. I call it issue because if this is something to be expected, i.e. the electron at the edge of BCAL creates showers in both calorimeters, then somehow g4 doesn't allow it. Or, if this is not likely to happen then g3 has a problem. As a first step, I plan to look at the data and see who is right.

Lubomir


From: Richard Jones notifications@github.com Sent: Sunday, March 7, 2021 8:11 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author author@noreply.github.com Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

Lubomir,

I wonder if you might look at what Sean wrote, and address it? Sean is saying that two things are being confused here, at least by me.

  1. associations of calorimeter clusters with tracks that are made at simulation time, and passed through the simulation Truth information recorded in the hddm record to the reconstruction and root trees;
  2. associations of calorimeter clusters with tracks that are formed during the event reconstruction, after tracks have been found and fitted, calorimeter clusters found, and a proximity test applied to the track projection onto the calorimeter surface. This association has no input from any simulation Truth information passed through the hddm record to the reconstruction and root trees.

Which of these two sources of association are you reporting here? If it is

2, I doubt I have much to offer you in terms of insight, as this is a

post-reconstruction track-cluster reconstruction issue. If the source of this association information is #1 then I may be able to contribute to the discussion.

-Richard Jones

On Sun, Mar 7, 2021 at 7:38 PM pentchev notifications@github.com wrote:

See bellow few of the events with theta >15 that I scanned. In the last six columns you have positron's FCAL, BCAL and measured momentum, and then the same for the electron. You can see the FCAL energy is EXACTLY the same for the electron and positron. Based on the momenta we can say that the positron deposited energy only in BCAL, but somehow in addition the signal in FCAL from the electron was assigned also to the positron.

root[13]epemB3_Tree->Scan("ChargedHypo__Energy_FCAL[PositronChargedIndex]:ChargedHypoEnergy_BCAL[PositronChargedIndex]:ChargedHypoP4_Measured[PositronChargedIndex].P():ChargedHypoEnergy_FCAL[ElectronChargedIndex]:ChargedHypoEnergy_BCAL[ElectronChargedIndex]:ChargedHypoP4_Measured[ElectronChargedIndex].P()","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypo__Energy_FCAL[Positron__ChargedIndex]>0")

  • Row Instance ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy

-

1279 0 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 1 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 2 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 3 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 4 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 5 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 6 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 7 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 8 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 9 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 10 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 11 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1947 0 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 1 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 2 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 3 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 4 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 5 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 6 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 7 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 8 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 9 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 10 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 11 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

3702 0 8.2515211 0.4371795 0.4544905 8.2515211 0 8.7837560

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792388981, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWGWBUCUVYH77UXEZ3TTCQMAFANCNFSM4YSAUSUA .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D792397533&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=Ng0LyRGOXZshqutgE326Ui4IKxIyLRBjNJnEYl-dq3o&s=4PRQJtQ5oCQH-j5rF2y2HSIv3xWalFT_5yAmBR1KCS4&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6QRY2S3KTHW7TWWQKTTCQP5LANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=Ng0LyRGOXZshqutgE326Ui4IKxIyLRBjNJnEYl-dq3o&s=hpm3tEN23ml9BddYtLoGXrv9XrOY-HT3sQdSX4GoTr4&e=.

pentchev commented 3 years ago

Sean,

The trees for the example I gave you are here:

/w/halld-scifs17exp/halld2/home/pentchev/dsoft/sim-recon/run/bh_mc/run/2018f_2020okg4/root/trees/*.root

You can see the run/event numbers bellow:

root [6] epemB3_Tree->Scan("RunNumber:EventNumber:ChargedHypo__Energy_FCAL[PositronChargedIndex]:ChargedHypoEnergy_BCAL[PositronChargedIndex]:ChargedHypoP4_Measured[PositronChargedIndex].P():ChargedHypoEnergy_FCAL[ElectronChargedIndex]:ChargedHypoEnergy_BCAL[ElectronChargedIndex]:ChargedHypoP4_Measured[ElectronChargedIndex].P()","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypoEnergy_FCAL[PositronChargedIndex]>0&&ChargedHypoP4_Measured[PositronChargedIndex].Theta()*57.3>15")



From: Sean Dobbs notifications@github.com Sent: Sunday, March 7, 2021 8:33 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author author@noreply.github.com Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

Lubomir: Thanks, could you please add the run/event numbers to these entries, along with the corresponding REST file? I feel like this must be a bug somewhere?

Richard: Indeed, these trees are at the level of your #2, but let's take a look at a couple of these simulated events, and we can see if we can give you something actionable.

---Sean

On Sun, Mar 7, 2021 at 8:11 PM Richard Jones notifications@github.com wrote:

Lubomir,

I wonder if you might look at what Sean wrote, and address it? Sean is saying that two things are being confused here, at least by me.

  1. associations of calorimeter clusters with tracks that are made at simulation time, and passed through the simulation Truth information recorded in the hddm record to the reconstruction and root trees;
  2. associations of calorimeter clusters with tracks that are formed during the event reconstruction, after tracks have been found and fitted, calorimeter clusters found, and a proximity test applied to the track projection onto the calorimeter surface. This association has no input from any simulation Truth information passed through the hddm record to the reconstruction and root trees.

Which of these two sources of association are you reporting here? If it is

2, I doubt I have much to offer you in terms of insight, as this is a

post-reconstruction track-cluster reconstruction issue. If the source of this association information is #1 then I may be able to contribute to the discussion.

-Richard Jones

On Sun, Mar 7, 2021 at 7:38 PM pentchev notifications@github.com wrote:

See bellow few of the events with theta >15 that I scanned. In the last six columns you have positron's FCAL, BCAL and measured momentum, and then the same for the electron. You can see the FCAL energy is EXACTLY the same for the electron and positron. Based on the momenta we can say that the positron deposited energy only in BCAL, but somehow in addition the signal in FCAL from the electron was assigned also to the positron.

root[13]epemB3_Tree->Scan("ChargedHypo__Energy_FCAL[PositronChargedIndex]:ChargedHypoEnergy_BCAL[PositronChargedIndex]:ChargedHypoP4_Measured[PositronChargedIndex].P():ChargedHypoEnergy_FCAL[ElectronChargedIndex]:ChargedHypoEnergy_BCAL[ElectronChargedIndex]:ChargedHypoP4_Measured[ElectronChargedIndex].P()","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypo__Energy_FCAL[Positron__ChargedIndex]>0")

  • Row Instance ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy

-

1279 0 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 1 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 2 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 3 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 4 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 5 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 6 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 7 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 8 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 9 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 10 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 11 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1947 0 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 1 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 2 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 3 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 4 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 5 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 6 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 7 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 8 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 9 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 10 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 11 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

3702 0 8.2515211 0.4371795 0.4544905 8.2515211 0 8.7837560

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792388981 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB3YKWGWBUCUVYH77UXEZ3TTCQMAFANCNFSM4YSAUSUA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792397533, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJAS2QJ4BHPIXDXGSNQU2DTCQP5LANCNFSM4YSAUSUA .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D792402713&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=BcRZbBKRq3PooU1SgreSstWTWxWfcmmrCp4b4SFybPM&s=kKnYb4mJK3MK5WES9YjdN_8ZSTvtsd62OJEOWjq3yRk&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6VNA2SC5KBPWYDOB6LTCQSNPANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=BcRZbBKRq3PooU1SgreSstWTWxWfcmmrCp4b4SFybPM&s=9mx3R1raMRcXZAzsEFwnfY3LCyo-a3qBn_dEx-Ejh_U&e=.

rjones30 commented 3 years ago

Lubomir,

Ok, good to know. If you come up with something actionable in terms of the output from the simulations please open an issue on github.com/Jeffersonlab/HDGeant4 with plots illustrating the problem.

-Richard Jones

On Sun, Mar 7, 2021 at 10:01 PM pentchev notifications@github.com wrote:

Richard,

In my last comment, for events with theta>15deg, I meant track-shower associations as in #2, i.e. during the event reconstruction and there's obviously a bug there.

However, the other group of events with theta<15 deg is present only in g3 but not in g4. That is why I assume that some differences in the simulations cause this issue. I call it issue because if this is something to be expected, i.e. the electron at the edge of BCAL creates showers in both calorimeters, then somehow g4 doesn't allow it. Or, if this is not likely to happen then g3 has a problem. As a first step, I plan to look at the data and see who is right.

Lubomir


From: Richard Jones notifications@github.com Sent: Sunday, March 7, 2021 8:11 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author < author@noreply.github.com> Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

Lubomir,

I wonder if you might look at what Sean wrote, and address it? Sean is saying that two things are being confused here, at least by me.

  1. associations of calorimeter clusters with tracks that are made at simulation time, and passed through the simulation Truth information recorded in the hddm record to the reconstruction and root trees;
  2. associations of calorimeter clusters with tracks that are formed during the event reconstruction, after tracks have been found and fitted, calorimeter clusters found, and a proximity test applied to the track projection onto the calorimeter surface. This association has no input from any simulation Truth information passed through the hddm record to the reconstruction and root trees.

Which of these two sources of association are you reporting here? If it is

2, I doubt I have much to offer you in terms of insight, as this is a

post-reconstruction track-cluster reconstruction issue. If the source of this association information is #1 then I may be able to contribute to the discussion.

-Richard Jones

On Sun, Mar 7, 2021 at 7:38 PM pentchev notifications@github.com wrote:

See bellow few of the events with theta >15 that I scanned. In the last six columns you have positron's FCAL, BCAL and measured momentum, and then the same for the electron. You can see the FCAL energy is EXACTLY the same for the electron and positron. Based on the momenta we can say that the positron deposited energy only in BCAL, but somehow in addition the signal in FCAL from the electron was assigned also to the positron.

root[13]epemB3_Tree->Scan("ChargedHypo__Energy_FCAL[PositronChargedIndex]:ChargedHypoEnergy_BCAL[PositronChargedIndex]:ChargedHypoP4_Measured[PositronChargedIndex].P():ChargedHypoEnergy_FCAL[ElectronChargedIndex]:ChargedHypoEnergy_BCAL[ElectronChargedIndex]:ChargedHypoP4_Measured[ElectronChargedIndex].P()","ChargedHypoEnergy_BCAL[PositronChargedIndex]>0&&ChargedHypo__Energy_FCAL[Positron__ChargedIndex]>0")

  • Row Instance ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy ChargedHy

-

1279 0 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 1 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 2 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 3 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 4 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 5 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 6 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 7 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 8 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 9 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 10 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1279 11 8.1523962 0.4766331 0.5221521 8.1523962 0 9.0334261

-

1947 0 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 1 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 2 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 3 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 4 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 5 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 6 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 7 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 8 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 9 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 10 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

1947 11 7.5676460 0.3747003 0.4983680 7.5676460 0 7.8884109

-

3702 0 8.2515211 0.4371795 0.4544905 8.2515211 0 8.7837560

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792388981 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB3YKWGWBUCUVYH77UXEZ3TTCQMAFANCNFSM4YSAUSUA

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D792397533&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=Ng0LyRGOXZshqutgE326Ui4IKxIyLRBjNJnEYl-dq3o&s=4PRQJtQ5oCQH-j5rF2y2HSIv3xWalFT_5yAmBR1KCS4&e=>, or unsubscribe< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6QRY2S3KTHW7TWWQKTTCQP5LANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=Ng0LyRGOXZshqutgE326Ui4IKxIyLRBjNJnEYl-dq3o&s=hpm3tEN23ml9BddYtLoGXrv9XrOY-HT3sQdSX4GoTr4&e=

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792426154, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWA76H73CGIIYLVPV4DTCQ4ZFANCNFSM4YSAUSUA .

zihlmann commented 3 years ago

Using DSelector to loop over combos in event looking for postron tracks and their associated shower energy. All tracks have only either BCAL energy or FCAL energy associated with them. Some tracks have no shower at all associated with them. Note these are all reconstructed tracks. the following two plots show the positron shower energy vers. angle when the associated shower for the track was in the FCAL for both GEANT3(first plot) and GEANT4(second plot). Note the two patches at 30deg. and 50deg. with large shower energy. this may associated with some reconstructed "ghost tracks". One question here would be: can the same shower be associated with two different tracks in the reconstruction code?

geant3_ep_FCAL geant4_ep_FCAL

rjones30 commented 3 years ago

Beni,

the following two plots show the positron shower energy vers. angle

What are you plotting?

Please clarify. thanks, -Richard

-Richard

On Mon, Mar 8, 2021 at 7:09 AM zihlmann notifications@github.com wrote:

the following two plots show the positron shower energy vers. angle when the associated shower for the track was in the FCAL for both GEANT3(first plot) and GEANT4(second plot) [image: geant3_ep_FCAL] https://user-images.githubusercontent.com/13365259/110319519-04cd5e80-7fdd-11eb-9cb1-f6b7e01eb73b.gif [image: geant4_ep_FCAL] https://user-images.githubusercontent.com/13365259/110319612-24648700-7fdd-11eb-97c4-d260adf1d875.gif

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-792713533, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWB7LVUTSSEAMI3T6M3TCS46VANCNFSM4YSAUSUA .

zihlmann commented 3 years ago

all values are RECONSTRUCTED. No truth information anywhere. the title should say what is ploted. vertical axis: The shower energy of the matched shower to the track the horizontal axis is the Theta() method of the TLorentzVector Class converted to degrees. Also this is of the reconstructed track. I loop over all combos in each event as every one else is doing with the DSelector. In that loop you will get a positron track and you can get its associated FCAL or BCAL matched shower like this: double ep_theta = locPositronP4.Theta()*180./3.1415926; double ep_EBCAL = dPositronWrapper->Get_Energy_BCAL(); double ep_EFCAL = dPositronWrapper->Get_Energy_FCAL(); double ep_BCALMatch = dPositronWrapper->Get_TrackBCAL_DeltaZ(); double ep_FCALMatch = dPositronWrapper->Get_TrackFCAL_DOCA();

If there is no match the return value for DeltaZ and DOCA are 999. conclusions: 1) there is NEVER a track that has a Match to both FCAL and BCAL shower. There is ALWAYS a match one calorimeter only either FCAL or BCAL. 2) with the caveat, there are some tracks that have NO match at all.

pentchev commented 3 years ago

Attached are plots showing (in the above order): FCAL vs BCAL signals and theta(thrown) vs BCAL for G3, and then the next two plots are the same but for G4. In G4 we don't see the ~10deg peak. At this level of analysis we don't have info about the truth shower energy.

Beni, I look directly at the trees, while you are using the DSelector, porbably that is why you never see events with signals in both calorimeters from one particle.


From: zihlmann notifications@github.com Sent: Monday, March 8, 2021 7:09 AM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author author@noreply.github.com Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

the following two plots show the positron shower energy vers. angle when the associated shower for the track was in the FCAL for both GEANT3(first plot) and GEANT4(second plot) [geant3_ep_FCAL]https://urldefense.proofpoint.com/v2/url?u=https-3A__user-2Dimages.githubusercontent.com_13365259_110319519-2D04cd5e80-2D7fdd-2D11eb-2D9cb1-2Df6b7e01eb73b.gif&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=iY_fLDauXgizbOAgtLhQovnw57XHunxpjYW9MvOuZ3E&s=yN4Aq53vlzob9Xax2mB-41AfWnEfXCDlPq0h8KMH8FU&e= [geant4_ep_FCAL]https://urldefense.proofpoint.com/v2/url?u=https-3A__user-2Dimages.githubusercontent.com_13365259_110319612-2D24648700-2D7fdd-2D11eb-2D97c4-2Dd260adf1d875.gif&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=iY_fLDauXgizbOAgtLhQovnw57XHunxpjYW9MvOuZ3E&s=vXXY_bDqcfeJwELxKnQVnxrBU89pG1gTnSoDogrvfgg&e=

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D792713533&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=iY_fLDauXgizbOAgtLhQovnw57XHunxpjYW9MvOuZ3E&s=pqKO1PPLaDHt_kezLJmLfOQWk0UEFhcka5p13kFdwUU&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6QB7H2J3AOPCMQD7KLTCS46VANCNFSM4YSAUSUA&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=iY_fLDauXgizbOAgtLhQovnw57XHunxpjYW9MvOuZ3E&s=hZRZv8I8abI1hWhucgCWTWWgVa9V8h9V-yiYbcDirOM&e=.

sdobbs commented 3 years ago

So, I found some interesting things.

Indeed, I'm seeing tracks matched to showers in both the BCAL and FCAL. Example:

======> EVENT:489
 RunNumber       = 50697
 EventNumber     = 961
[snip]
 ChargedHypo__TrackID = 1, 
                  2, 3
[snip]
 ChargedHypo__Energy_BCAL = 0.476633, 
                  0.0978425, 0
[snip]
 ChargedHypo__Energy_FCAL = 8.1524, 
                  0, 8.1524

Note that both tracks are matched to the same FCAL shower!

So, I looked at an event display:

Screen Shot 2021-03-08 at 5 38 55 PM

It's not clear to me how either of those tracks that hit the BCAL - except it looks like one of them starts to curve back, doesn't it? So it could possible be matched to a BCAL shower, then follow the extrapolation curving back around to eventually hitting the FCAL, where this other shower is.

Simon confirmed that the track extrapolation code which is used to determine the track/shower matching allows the track to exit the BCAL and be matched to an FCAL shower - makes sense in the transition region, but this is a degenerate case.

So, I guess the question for @rjones30 and/or Simon is how this matching could vary between the different simulations? I thought the same material model was used for reconstruction in both cases? So maybe there's some subtle difference in the simulation which leads to these showers and tracks not being erroneously matched? Strange.

rjones30 commented 3 years ago

So, I guess the question for @rjones30 https://github.com/rjones30 and/or Simon is how this matching could vary between the different simulations?

This looks like a track extrapolation bug. No e+/e- track is able to go through that much BCAL material. Why this bug would be present in G3 simulation results and not G4 would depend on how the bug comes about. Have you tried stripping out all Truth information from the hddm files and leave only the bare hits data to the reconstruction. In this case, I cannot see how any algorithm could tell which simulation was the source.

-Richard

On Mon, Mar 8, 2021 at 5:58 PM Sean Dobbs notifications@github.com wrote:

So, I found some interesting things.

Indeed, I'm seeing tracks matched to showers in both the BCAL and FCAL. Example: root [3] epemB3_Tree->Show(489) ======> EVENT:489 RunNumber = 50697 EventNumber = 961 [snip] ChargedHypoTrackID = 1, 2, 3 [snip] ChargedHypoEnergy_BCAL = 0.476633, 0.0978425, 0 [snip] ChargedHypoEnergy_FCAL = 8.1524, 0, 8.1524 Note that both tracks are matched to the same FCAL shower!

So, I looked at an event display: [image: Screen Shot 2021-03-08 at 5 38 55 PM] https://user-images.githubusercontent.com/1182058/110392245-9fa65700-8036-11eb-9324-a619847274cb.png

It's not clear to me how either of those tracks that hit the BCAL - except it looks like one of them starts to curve back, doesn't it? So it could possible be matched to a BCAL shower, then follow the extrapolation curving back around to eventually hitting the FCAL, where this other shower is.

Simon confirmed that the track extrapolation code which is used to determine the track/shower matching allows the track to exit the BCAL and be matched to an FCAL shower - makes sense in the transition region, but this is a degenerate case.

So, I guess the question for @rjones30 https://github.com/rjones30 and/or Simon is how this matching could vary between the different simulations? I thought the same material model was used for reconstruction in both cases? So maybe there's some subtle difference in the simulation which leads to these showers and tracks not being erroneously matched? Strange.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-793148551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWFL3AODPCGBNOGPEZ3TCVJA7ANCNFSM4YSAUSUA .

pentchev commented 3 years ago

Note, the examples Sean made correspond to big lepton angles and they are present in both geants. The difference between G3 and G4 appears for forward, ~10 deg high momentum leptons that may hit BCAL at the edge, deposit most of its energy (several GeV) there but also (in G3) some fraction (few hundred MeV) in FCAL. First look at the data is in favor of G4, almost no such events at ~10 deg, while the big angle events are there. Plots with data results will follow soon.


From: Richard Jones notifications@github.com Sent: Monday, March 8, 2021 8:10 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author author@noreply.github.com Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

So, I guess the question for @rjones30 https://github.com/rjones30 and/or Simon is how this matching could vary between the different simulations?

This looks like a track extrapolation bug. No e+/e- track is able to go through that much BCAL material. Why this bug would be present in G3 simulation results and not G4 would depend on how the bug comes about. Have you tried stripping out all Truth information from the hddm files and leave only the bare hits data to the reconstruction. In this case, I cannot see how any algorithm could tell which simulation was the source.

-Richard

On Mon, Mar 8, 2021 at 5:58 PM Sean Dobbs notifications@github.com wrote:

So, I found some interesting things.

Indeed, I'm seeing tracks matched to showers in both the BCAL and FCAL. Example: root [3] epemB3_Tree->Show(489) ======> EVENT:489 RunNumber = 50697 EventNumber = 961 [snip] ChargedHypoTrackID = 1, 2, 3 [snip] ChargedHypoEnergy_BCAL = 0.476633, 0.0978425, 0 [snip] ChargedHypoEnergy_FCAL = 8.1524, 0, 8.1524 Note that both tracks are matched to the same FCAL shower!

So, I looked at an event display: [image: Screen Shot 2021-03-08 at 5 38 55 PM] https://user-images.githubusercontent.com/1182058/110392245-9fa65700-8036-11eb-9324-a619847274cb.png

It's not clear to me how either of those tracks that hit the BCAL - except it looks like one of them starts to curve back, doesn't it? So it could possible be matched to a BCAL shower, then follow the extrapolation curving back around to eventually hitting the FCAL, where this other shower is.

Simon confirmed that the track extrapolation code which is used to determine the track/shower matching allows the track to exit the BCAL and be matched to an FCAL shower - makes sense in the transition region, but this is a degenerate case.

So, I guess the question for @rjones30 https://github.com/rjones30 and/or Simon is how this matching could vary between the different simulations? I thought the same material model was used for reconstruction in both cases? So maybe there's some subtle difference in the simulation which leads to these showers and tracks not being erroneously matched? Strange.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-793148551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWFL3AODPCGBNOGPEZ3TCVJA7ANCNFSM4YSAUSUA .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D793230222&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=1c0EhiyQxtHL28D_ltTHiHnkB4DBmZm7cspXHBmvTMI&s=MEny35fxMc1hMpTAqgP1uUPy9zlb1wkQB7JESDshFco&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6RA4F36ZYDDIDPA6WDTCVYRBANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=1c0EhiyQxtHL28D_ltTHiHnkB4DBmZm7cspXHBmvTMI&s=oLxhfNR1BAKew-M3ufdYRtGvFSN4pGX_Pan1mNhFwJM&e=.

rjones30 commented 3 years ago

Lubomir,

When you do this comparison, make sure that you do not only include the FCAL energy that gets made into clusters. You have to sum up all of the energy from all of the blocks. Most of the spray that comes through from the tails of the shower in the BCAL gets turned into a fine mist that covers a whole region of the FCAL and is not captured by clusters. My guess is that only a small fraction is actually seen as clusters in the fcal, maybe only a few percent, and this fraction might be very different in the two simulations because of the much lower minimum energy that hdgeant4 uses in following the showers. In hdgeant the showers are more coarse-grained than in hdgeant4, which might make the clusterization of the spray in the fcal slightly more efficient at the few-percent level.

-Richard Jones

On Mon, Mar 8, 2021 at 10:37 PM pentchev notifications@github.com wrote:

Note, the examples Sean made correspond to big lepton angles and they are present in both geants. The difference between G3 and G4 appears for forward, ~10 deg high momentum leptons that may hit BCAL at the edge, deposit most of its energy (several GeV) there but also (in G3) some fraction (few hundred MeV) in FCAL. First look at the data is in favor of G4, almost no such events at ~10 deg, while the big angle events are there. Plots with data results will follow soon.


From: Richard Jones notifications@github.com Sent: Monday, March 8, 2021 8:10 PM To: JeffersonLab/HDGeant4 HDGeant4@noreply.github.com Cc: Lubomir Pentchev pentchev@jlab.org; Author < author@noreply.github.com> Subject: [EXTERNAL] Re: [JeffersonLab/HDGeant4] hits in both CALs from the same track (#185)

So, I guess the question for @rjones30 https://github.com/rjones30 and/or Simon is how this matching could vary between the different simulations?

This looks like a track extrapolation bug. No e+/e- track is able to go through that much BCAL material. Why this bug would be present in G3 simulation results and not G4 would depend on how the bug comes about. Have you tried stripping out all Truth information from the hddm files and leave only the bare hits data to the reconstruction. In this case, I cannot see how any algorithm could tell which simulation was the source.

-Richard

On Mon, Mar 8, 2021 at 5:58 PM Sean Dobbs notifications@github.com wrote:

So, I found some interesting things.

Indeed, I'm seeing tracks matched to showers in both the BCAL and FCAL. Example: root [3] epemB3_Tree->Show(489) ======> EVENT:489 RunNumber = 50697 EventNumber = 961 [snip] ChargedHypoTrackID = 1, 2, 3 [snip] ChargedHypoEnergy_BCAL = 0.476633, 0.0978425, 0 [snip] ChargedHypoEnergy_FCAL = 8.1524, 0, 8.1524 Note that both tracks are matched to the same FCAL shower!

So, I looked at an event display: [image: Screen Shot 2021-03-08 at 5 38 55 PM] < https://user-images.githubusercontent.com/1182058/110392245-9fa65700-8036-11eb-9324-a619847274cb.png

It's not clear to me how either of those tracks that hit the BCAL - except it looks like one of them starts to curve back, doesn't it? So it could possible be matched to a BCAL shower, then follow the extrapolation curving back around to eventually hitting the FCAL, where this other shower is.

Simon confirmed that the track extrapolation code which is used to determine the track/shower matching allows the track to exit the BCAL and be matched to an FCAL shower - makes sense in the transition region, but this is a degenerate case.

So, I guess the question for @rjones30 https://github.com/rjones30 and/or Simon is how this matching could vary between the different simulations? I thought the same material model was used for reconstruction in both cases? So maybe there's some subtle difference in the simulation which leads to these showers and tracks not being erroneously matched? Strange.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-793148551 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB3YKWFL3AODPCGBNOGPEZ3TCVJA7ANCNFSM4YSAUSUA

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_185-23issuecomment-2D793230222&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=1c0EhiyQxtHL28D_ltTHiHnkB4DBmZm7cspXHBmvTMI&s=MEny35fxMc1hMpTAqgP1uUPy9zlb1wkQB7JESDshFco&e=>, or unsubscribe< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALUST6RA4F36ZYDDIDPA6WDTCVYRBANCNFSM4YSAUSUA&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=IinLSL4VI2fknYdfDE7M2gBFgBtC_5BdQNGqLeu4HZg&m=1c0EhiyQxtHL28D_ltTHiHnkB4DBmZm7cspXHBmvTMI&s=oLxhfNR1BAKew-M3ufdYRtGvFSN4pGX_Pan1mNhFwJM&e=

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-793331260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWGYEEKRLLWVAGRKA3LTCWJXTANCNFSM4YSAUSUA .

pentchev commented 3 years ago

In this plot I'm comparing the theta distributions for such events (with non-zero signals in both BCAL and FCAL associated to the same lepton) from the data, G4, and G3. Note that I have to apply cuts to select BH from the data and I'm applying the same cuts in MC, as a result the 10deg peak in G3 is smaller compared to the events at theta>15deg, which was not the case without these cuts. Richard: I agree that to study these effects, you want to sum all the energy in FCAL. At the same time, when comparing to the data, you don't have to do this as the event reconstruction is the same in data and MC.

rjones30 commented 3 years ago

Lubomir,

Ok, as long as you are aware that these events you are capturing with that requirement might be some edge case, such as a hard hadronic interaction in the lead that produces a stiff forward particle. Such a thing will be difficult to reproduce consistently without fine-tuning the Monte Carlo. This is why just compare just two simulations: hdgeant4 vs hdgeant always gives an incomplete picture.To get a convincing comparison, you always want to compare three simulations: hdgeant(HADR=1), hdgeant(HADR=4), and hdgeant4.

-Richard Jones

On Tue, Mar 9, 2021 at 11:07 AM pentchev notifications@github.com wrote:

In this plot http://www.jlab.org/Hall-D/detector/fdc/BothCal_comp_data.pdf I'm comparing the theta distributions for such events (with non-zero signals in both BCAL and FCAL associated to the same lepton) from the data, G4, and G3. Note that I have to apply cuts to select BH from the data and I'm applying the same cuts in MC, as a result the 10deg peak in G3 is smaller compared to the events at theta>15deg, which was not the case without these cuts. Richard: I agree that to study these effects, you want to sum all the energy in FCAL. At the same time, when comparing to the data, you don't have to do this as the event reconstruction is the same in data and MC.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/185#issuecomment-794096026, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWFTGRKMKKJJQAIZLSTTCY2THANCNFSM4YSAUSUA .

sdobbs commented 3 years ago

For the difference in EM showers in the transition region between G3 and G4, you can also look at some results from a study by Mark Dalton, which I think also saw a larger spray in G4: https://halldweb.jlab.org/DocDB/0039/003949/002/presentation_fiducialcut_v2.pdf

markito3 commented 3 years ago

@pentchev : go ahead and close it, it affects a very small percentage of events and is mostly of academic interest.