unexpected jumps in MC yield vs photon energy

[rjones30]

These results for MC efficiency were shown by Hao Li at the February, 2021 collaboration meeting, for the reaction gamma,p -> p,pbar,p. Notice the jumps that appear between the TAGM region 7.8-8.8 GeV and the TAGH regions above and below it.

[rjones30]

Justin asks: Are you using the mcthrown_tree plugin and output tree for computing the efficiency, which removes generated events which don’t have the correct detected beam photon. Some description of this was shown at the Analysis Workshop in 2019 https://halldweb.jlab.org/DocDB/0040/004008/002/tutorial2019_session0g.pdf. That would be the first thing I’d like to check to understand this discontinuity.

[rjones30]

Hao responds: Yes, the denominator of the efficiency formula is mcthrown_trees. Usually I generated 1 million events, and it become ~970000 events after non-tagged beam photons removed.

[rjones30]

Justin replies: Do you have a plot of the photon beam energy from this mcthrown_tree of generated events after non-tagged beam photons are removed? This would help diagnose or understand where this discontinuity in the efficiency is coming from. The analogous plot from the 2019 workshop is the left panel of slide 17.

[lihaoahil]

@jrstevenjlab here is the mcthrown_tree beam energy:

[jrstevenjlab]

Thanks @lihaoahil. The gaps in the TAGH at low energy seem to be there as expected, so if this is the denominator of your efficiency calculation it should be properly exclude the tagger geometrical gaps from the efficiency you use in the cross section calculation.

This still leaves the unphysical "step" in the efficiency at the tagger boundary. So a couple more questions: 1) When you compute the yield for the numerator of your efficiency, do you subtract accidentals? 2) Could you calculate the efficiency for MC from amorphous and diamond runs separately? If there is an accidental effect due to the coherent peak it would be seen in one and not the other.

[lihaoahil]

@jrstevenjlab For question#1, yes, I used the dAnalysisUtilities.Get_AccidentalScalingFactor() to do the subtraction in both data and observed MC. For question#2, sure, let me rerun my dselector with polarization selection and I will get back to you once I have that plotted!

[rjones30]

The accidentals scaling factor should not be used for MC, only for data. Do you include tagger accidentals in your simulation? They could come into simulation either through the random hits injection, or through the BGRATE/BGGATE option in control.in, or both if you enable both of them. Can you report how these options are handled in your simulation?

-Richard Jones

On Fri, Feb 19, 2021 at 11:02 AM Hao Li notifications@github.com wrote:

@jrstevenjlab https://github.com/jrstevenjlab For question#1, yes, I used the dAnalysisUtilities.Get_AccidentalScalingFactor() to do the subtraction in both data and observed MC. For question #2 https://github.com/JeffersonLab/HDGeant4/pull/2, sure, let me rerun my dselector with polarization selection and I will get back to you once I have that plotted!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/183#issuecomment-782169347, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWEZRKNM4UI4GNWUZ7DS72DS5ANCNFSM4X4SAGUQ .

[lihaoahil]

@rjones30 Hi I am using MCWrapper for all the simulations. I have added random triggers for all run periods. In the control.in, I just checked, the following options are set up like this: "cBGGATE -200. 200." "cBGRATE rcdb", which I believe they are commented out? Another question, if scaling factor is only used for data, not mc, then what is the mc flag for in the command "ccdb dump ANALYSIS/accidental_scaling_factor -v mc -r"?

[sdobbs]

Right, the function call you're using is set up to correctly return "1" if you're running over MC (i.e. no scaling correction).

On Fri, Feb 19, 2021 at 11:19 AM Hao Li notifications@github.com wrote:

@rjones30 https://github.com/rjones30 Hi I am using MCWrapper for all the simulations. I have added random triggers for all run periods. In the control.in, I just checked, the following options are set up like this: "cBGGATE -200. 200." "cBGRATE rcdb", which I believe they are commented out? Another question, if scaling factor is only used for data, not mc, then what is the mc flag for in the command "ccdb dump ANALYSIS/accidental_scaling_factor -v mc -r"?

— 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/183#issuecomment-782178998, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJAS2S3RJLZDYCAYNUFQCLS72FRJANCNFSM4X4SAGUQ .

[rjones30]

I see no red flags there.

[lihaoahil]

Right, the function call you're using is set up to correctly return "1" if you're running over MC (i.e. no scaling correction). … On Fri, Feb 19, 2021 at 11:19 AM Hao Li @.***> wrote: @rjones30 https://github.com/rjones30 Hi I am using MCWrapper for all the simulations. I have added random triggers for all run periods. In the control.in, I just checked, the following options are set up like this: "cBGGATE -200. 200." "cBGRATE rcdb", which I believe they are commented out? Another question, if scaling factor is only used for data, not mc, then what is the mc flag for in the command "ccdb dump ANALYSIS/accidental_scaling_factor -v mc -r"? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#183 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJAS2S3RJLZDYCAYNUFQCLS72FRJANCNFSM4X4SAGUQ .

@sdobbs Got it! I will add that flag in my dselector to avoid using scaling factor on mc. Thanks!

[sdobbs]

Sorry if I wasn't clear - you shouldn't have to do anything special if you are running over MC - the framework already returns the correct value.

On Fri, Feb 19, 2021 at 11:34 AM Hao Li notifications@github.com wrote:

Right, the function call you're using is set up to correctly return "1" if you're running over MC (i.e. no scaling correction). … <#m-6146323731685159681> On Fri, Feb 19, 2021 at 11:19 AM Hao Li @.***> wrote: @rjones30 https://github.com/rjones30 https://github.com/rjones30 Hi I am using MCWrapper for all the simulations. I have added random triggers for all run periods. In the control.in, I just checked, the following options are set up like this: "cBGGATE -200. 200." "cBGRATE rcdb", which I believe they are commented out? Another question, if scaling factor is only used for data, not mc, then what is the mc flag for in the command "ccdb dump ANALYSIS/accidental_scaling_factor -v mc -r"? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#183 (comment) https://github.com/JeffersonLab/HDGeant4/issues/183#issuecomment-782178998>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJAS2S3RJLZDYCAYNUFQCLS72FRJANCNFSM4X4SAGUQ .

@sdobbs https://github.com/sdobbs Got it! I will add that flag in my dselector to avoid using scaling factor on mc. Thanks!

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

[aaust]

@lihaoahil Do you bin the reconstructed events, i.e. the numerator of the efficiency, in the reconstructed energy or the thrown energy?

[lihaoahil]

Hi Alex,

I used the reconstructed energy (kinfit value).

On Fri, Feb 19, 2021 at 12:19 PM Alex Austregesilo notifications@github.com wrote:

@lihaoahil https://github.com/lihaoahil Do you bin the reconstructed events, i.e. the numerator of the efficiency, in the reconstructed energy or the thrown energy?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/HDGeant4/issues/183#issuecomment-782215454, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACKXPQFJR6JAMYO4SFIU2DDS72MQRANCNFSM4X4SAGUQ .

--

Hao Li University of Illinois at Urbana-Champaign College of Liberal Arts and Sciences Physics Major | Mathematics Major Phone: 217-979-8664 Email: *lihaoahil@gmail*.com lihaoahil@gmail.com

[aaust]

Can you please check if using the thrown energy to bin the numerator has a significant impact on the result? This should avoid resolution effects at the bin boundaries.

[lihaoahil]

Can you please check if using the thrown energy to bin the numerator has a significant impact on the result? This should avoid resolution effects at the bin boundaries.

That is a good idea! I will try that. Thank you Alex!

[rjones30]

I have introduced a fix to the Master branch of hdgeant4 that I believe may fix this issue. Can you regenerate your sample using the latest Master of HDGeant4 and plot again the MC efficiency vs energy to see if the jumps at the TAGM/TAGH boundaries have gone away? -Richard

[rjones30]

Closing this issue because of no action for 6 months. If it comes back up, it can be opened back up. -Richard

[rjones30]

Closing this issue because of no action for 6 months. If it comes back up, it can be opened back up. -Richard