FCAL (linear/non-linear) energy correction below 1 GeV for simu & data

[igjaegle]

There is a bug in DFCALShower_factory, the wrong string is used to retrieve the cutoff energy in the database resulting in having the cutoff energy to always be set to 0 GeV.

As noted in https://logbooks.jlab.org/entry/3810677, if corrected as is, it will lead to un-physical results below 1 GeV.

The solution relies on understanding the causes of the non-linearity. Shower leakage? Threshold? Transparency?

[igjaegle]

The standard GlueX gains matching is done for cluster energies above 800 MeV using a non-linear correction corresponding to the following function [0]-exp(-[1]*x+[2]). The non-linear correction for energies below 800 MeV in data & simu corresponded so far to the extrapolation of the function discussed above. The FIG below shows that the extrapolation is just wrong for simu and most probably also for data.

Furthermore, the function [0]-exp(-[1]*x+[2]) starts to diverge from the simu below 1.8 GeV.

More appropriate functions are 1/ between 1.8 and 10 GeV, [0]-exp(-[1]x-[2]xx+[3]) 2/ between 0.12 and 1.8 GeV, [0]-exp(-[1]x-[2]xx-[3]xx*x+[4]) 3/ between 0.05 and 0.12 GeV, exp(pol2)-[3]

[mashephe]

Labels would make your plot a lot easier to interpret.

Also to my knowledge we put a 100 MeV cut on photons used for analysis. It doesn’t make much sense to push below that point, which is already, I think, more aggressive than the initial design spec of the detector.

On May 20, 2020, at 5:56 PM, igjaegle notifications@github.com wrote:

 The standard GlueX gains matching is done for cluster energies above 800 MeV using a non-linear correction corresponding to the following function [0]-exp(-[1]*x+[2]). The non-linear correction for energies below 800 MeV in data & simu corresponded so far to the extrapolation of the function discussed above. The FIG below shows that the extrapolation is just wrong for simu and most probably also for data.

Furthermore, the function [0]-exp(-[1]*x+[2]) starts to diverge from the simu below 1.8 GeV.

More appropriate functions are 1/ between 1.8 and 10 GeV, [0]-exp(-[1]*x-[2]xx+[3]) 2/ between 0.12 and 1.8 GeV, [0]-exp(-[1]x-[2]xx-[3]xxx+[4]) 3/ between 0.05 and 0.12 GeV, exp(pol2)-[3]

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[igjaegle]

The red curve corresponds to the standard GlueX function: [0]-exp(-[1]*x+[2])

NB, the so-called linear part in the shower factory as I already mentioned elsewhere (https://github.com/JeffersonLab/halld_sim/issues/125) was never used because of a bug in the labeling!

My recommendations are to use

1/ between 1.8 and 10 GeV, [0]-exp(-[1]x-[2]xx+[3]) 2/ between 0.12 and 1.8 GeV, [0]-exp(-[1]x-[2]xx-[3]*xxx+[4]) and a 150 MeV energy cluster threshold for photons.

Also, one should check that this cut is also applied in the software trigger.

To validate my recommendations in the next GlueX monitoring launch a new pi0 skim with cluster energies above 50MeV will be included.