[Halld-offline] FCAL Calibration: Data vs. MC

[Richard Jones]

Hello Matt,

I agree with the procedure you outlined. The only thing I would suggest is
that, at the same time as you apply an improved non-linear correction to
the shower energies for real data, pass that function to me and I will
apply it as a parameterized factor in computing the block energies in
HDGeant. Eventually we should have the MC mimic the real behavior of the
detector, so we can keep to the standard practice of using the same
analysis path for either MC or real events.

-Richard J.

On Fri, Sep 19, 2014 at 8:41 AM, Matthew Shepherd <mashephe at indiana.edu>
wrote:

>
> Richard,
>
> Thanks for reminding us of the important details regarding
> attenuation.  Basically you outline the procedure I had
> envisioned, with the exception of starting with a nonlinear
> correction derived from MC.  I thought of omitting that
> initially to decouple data from MC and then going back
> and tuning the MC to match.  However, tuning block gains
> based on pi0 mass alone (with no shower-level correction)
> is, as I realize now, somewhat arbitrary as an overall
> gain scale related to the avg. photon energy in pi0
> decays will be incorporated into the constant.  I agree it
> may be best to seed the process with an MC motivated
> shower correction and then go back and retune that
> correction once initial block-level gains are determined.
> For ease of interpretation, I would prefer the gain constants
> be around unity.  (This is also useful when compensating
> gain with HV adjustments.)  To do this, I may have to
> renormalize the shower-level correction.  An difference
> in non-linear behavior of MC from data, will has to be
> tuned separately with some adjustment of MC response.
>
> Matt
>
> ---------------------------------------------------------------------
> Matthew Shepherd, Associate Professor
> Department of Physics, Indiana University, Swain West 265
> 727 East Third Street, Bloomington, IN 47405
>
> Office Phone:  +1 812 856 5808
>
> On Sep 19, 2014, at 6:08 AM, Richard Jones <richard.t.jones at uconn.edu>
> wrote:
>
> > Hello Matt and all,
> >
> > The question is, do we calibrate the detector such
> > that the result of calibration is actual energy in GeV or
> > the output of HDGEANT?  (Maybe the difference between
> > these is imperceptible, but I don't think it will be.)
> >
> >
> > By "energy loss" I presume that you mean energy leakage out the front or
> back of the blocks, and through the sides into blocks whose deposition is
> below threshold for inclusion in the sum. These effects are there at the
> few percent level, but this is not the main source of the difference
> between the energy sum in the calorimeter blocks and the incident gamma
> energy. The main source of this difference in the simulation comes from the
> attenuation of Cerenkov light in the glass between the point where it is
> generated and the back of the block where it is seen by the phototube. This
> attenuation is applied in HDGeant because after the shower deposition has
> been summed, the depth info in the block is lost.  Depth fluctuations in
> shower development are a significant contribution to the overall energy
> resolution for high-energy showers, because of attenuation and leakage,
> with attenuation being the primary effect. So the units for the block pulse
> height from simulation are in GeV but this needs to be corrected by an
> energy-dependent factor (the average shower depth goes like the log of
> Egamma) before it is taken to represent the actual energy of the gamma in
> GeV. This will be the same in the real data. Some important facts to point
> out about this:
> >       • the correction from observed pulse height to actual shower
> energy is non-linear because average shower depth goes like log(E);
> >       • the correction can depend on incidence angle, so it may have to
> include theta-dependence (we had to have that in Radphi because we were
> only 1m from the target) although for GlueX this is probably negligible;
> >       • the correction from observed pulse height to shower energy can
> only be applied after the total energy of the shower is known, not at a
> block-by-block level. So the correction needs to be post-clusterization,
> because the only real handle we have on the average shower depth is the
> shower energy.
> >
> >
> > I think what we want to do is calibrate such that it is
> > actual energy in GeV.  Then we want to adjust the
> > shower-level calibration appropriately.  What we do
> > NOT want to do is have a branch that applies different
> > shower level correction for MC and data.
> >
> >
> > I am not sure what you mean by "actual energy" here. There is really no
> way to take out the attenuation effect at the block level. That can only be
> done after the cluster sum is made. The way the FCAL calibration system
> worked in E852 and in Radphi was that MC was used to obtain a non-linear
> function that maps the shower block energy sum to incident gamma energy.
> This same correction was in place and applied when the calibration began,
> using real data.
> >       • With real data, starting with an approximate gain match between
> all of the blocks that was obtained using the pulser system, it was already
> possible to see a clear pi0 peak in the 2-cluster mass distribution.
> >       • A global scale factor was found that would place the pi0 mass at
> 135 MeV.
> >       • The array of individual block gains was set up, one for each
> block, and initialized to 1.
> >       • A large sample of real data containing many many pi0's was taken
> for calibration, and a global fit was performed to minimize the width of
> the pi0 peak by varying all of the block gains as fit parameters. This
> turns out to converge well and is fairly fast.
> >       • After convergence, these gains were saved to the calibrations
> database and used to analyze another (different) large sample of events
> with plenty of pi0's from the same run period. We used this to confirm that
> the observed pi0 width was within expectations.
> >       • Now with real data and an initial calibration, we went back and
> reviewed the non-linear correction function that was based originally on MC
> and apply tweaks to make it match the actual FCAL performance better.
> > It would take a paragraph to describe how #6 was accomplished. But this
> brief description should be sufficient for our purposes here.
> >
> >
> > This means that, post run, we need to devise an algorithm to
> > produce the same calibrated block-level energy from
> > the energy deposited per bock as recorded by HDGEANT.
> > I don't think there is a way to know in advance if
> > this is a single common algorithm for all blocks or
> > will need tuning on a block by block basis.  (We
> > may need additional constants.)
> >
> >
> > By this I think you mean what I am calling the non-linear correction
> from block sum to cluster energy. Is that what you mean? If so, I think you
> will find that a single function works well for all of the blocks except
> possibly the innermost ones right around the hole (we had to apply a
> special leakage correction there, not very pretty) and that the need for a
> theta-dependence in the non-linear function parameters will not be needed
> for GlueX. In Radphi we found that below 10 degrees the variation in the
> correction function parameters was barely visible.
> >
> >
> >
> > To prepare for actual data, we will generate EVIO
> > output of HDGEANT and then try to calibrate the block
> > level constants using the output of DFCALCluster_factory.
> >
> > We can then look at invariant mass of clusters (no
> > shower level energy correction applied) and that should
> > peak at the pi0 mass.  Applying shower-level nonlinearly
> > corrections, which will have to be derived later, should
> > improve resolution, but not necessary from the outset
> > (and may want to be turned off if it is not working
> > properly).
> >
> >
> > You could do it this way, but I would not suggest it because you are
> driving a wedge between the way that you handle MC and the way that real
> data are treated. Why not just allow the non-linear correction that is
> already being applied in the post-clusterizer stage be applied to the real
> data, and treat the gains as free fit parameters that you adjust so as to
> make the final pi0 mass peak appear at the right place with the minimum
> width? This will automatically make all of your block gains mimic what the
> MC does in producing an attenuation-corrected energy deposition in GeV.
> >
> >
> >
> > Where can I find the code that applies this overall
> > multiplicative constant to convert pulse integral to
> > energy (and what is assumed value in the current EVIO
> > output plugin)?  Where do the block level constants
> > get applied?  Sean has given me some preliminary
> > info on how to rewrite these.
> >
> >
> >
> > I can point you to where this is done, but first we should agree on the
> above issues.
> >
> > -Richard Jones
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20140919/ad9e0e6b/attachment-0002.html>