[Halld-offline] HDGeant4 Meeting Minutes, February 23, 2021

[Mark Ito]

Folks,

Please find the minutes here 
<https://halldweb.jlab.org/wiki/index.php/HDGeant4_Meeting,_February_23,_2021#Minutes> 
and below.

Recall that your secretary had a loose grasp on some of the particulars 
of the tagger energy discussion. Comments and corrections welcome. If 
you would like to modify the wiki directly, feel free.

   -- Mark

    ________________________________


    HDGeant4 Meeting, February 23, 2021, Minutes

Present: Tegan Beattie, Sean Dobbs, Mark Ito (chair), Igal Jaegle, 
Richard Jones, Zisis Papandreou, Justin Stevens, Simon Taylor, Nilanga 
Wickramaarachchi, Beni Zihlmann

There is a recording of this meeting 
<https://bluejeans.com/s/sjAsRH5bnJD/> on the BlueJeans site. Log into 
the BlueJeans site first to gain access (use your JLab credentials).


      Review of minutes from the last meeting

We went over the minutes from February 9 
<https://halldweb.jlab.org/wiki/index.php/HDGeant4_Meeting,_February_9,_2021#Minutes> 
without much comment.


      Issues on GitHub


        Incorrect TAGH counter number assignment

This is Issue #182 
<https://github.com/JeffersonLab/HDGeant4/issues/182>. Richard and Igal 
introduced the issue and the proposal. Sean and Justin made significant 
contributions to discussion that shaped the proposal.


          The Issue

 1. Photon energy (E_γ ) is measured as the difference between the
    electron beam energy (E_beam ) and the post-bremsstrahlung electron
    energy corresponding to a particular tagger counter (E_tag ).
 2. E_tag is determined from a lookup table, which defines the lower and
    upper energy limits of each counter. The lookup table itself is
    recorded as a fraction (f) of an overall scale (E_scale ), so the
    entries in the table are all greater than zero and less than one and
    each tagger counter has an f_low and an f_high . After E_scale is
    supplied, simple multiplication transforms the table entries into
    the desired set of energy bin limits.
 3. E_scale depends on the tagger magnet current. In particular, it is
    independent of the electron beam energy.
 4. An approximation that we have used in the past in both simulation
    and reconstruction is setting E_scale equal to E_beam . This is what
    MCC tries to do at the beginning of each run, roughly speaking.
    Let's call this the "*approximate scheme*."
 5. The approximate scheme has two defects: (1) the electron beam energy
    can fluctuate during the course of the run and (2) the tagger magnet
    current (and thus E_scale ) is different for each run period.
 6. There is no practical reason to use the approximate scheme, since
    both E_beam and E_scale are known on a run-by-run basis
    independently and we can apply E_γ = E_beam - f*E_scale
    unambiguously. Let's call this the *exact scheme*. (Yes, not exactly
    exact, but we are just defining terms here.)
 7. In addition there is code in the simulation that purposefully
    inserts an error into the reported tagger energy. The error is a
    smooth function of E_tag . This was done to provide an exercise for
    measuring such errors and taking them out in the days before the
    Hall was commissioned. Inadvertently, it remains in the code. Let's
    call this the tagger energy *skew*.
 8. In the asymptotic past, we used the approximate scheme for both
    simulation and reconstruction. We also had the skew in the simulation.
 9. Recently (about a year ago), the reconstruction was changed to use
    the exact scheme. The simulation continued to use the approximate
    scheme and the skew remained as well.
10. HDGeant/HDGeant4 outputs data in HDDM format. It reports both the
    tagger counter ID and the energy corresponding to the middle of the
    energy bin.
11. mcsmear does not modify these tagger quantities.
12. The reconstruction (hd_root) outputs its data in REST format. It
    reports only the energy, and not the tagger counter ID.


          Observations

 1. For the past year or so, we have been using inconsistent schemes for
    determining E_tag between simulation and reconstruction. This has
    led to the observed anomalies, in particular where reported energies
    appear not to correspond to any physical tagger counter.
 2. The REST data encodes the energy scheme (approximate or exact) in
    the tagger energy. Recall that the REST does not record the tagger
    counter ID.


          Philosophy going forward

 1. Use the exact scheme everywhere.
 2. Communicate tagger energy from program to program via tagger counter
    ID.


          Proposal

 1. Remove the skew from the simulation.
 2. Change the simulation to use the exact scheme. (The change is
    already present in the current reconstruction.)
 3. Change the REST format to accommodate recording of the tagger
    counter ID.
 4. Change the REST reader to use the tagger counter ID to calculate E_tag .


          Implications

 1. Previously produced simulated data needs to be re-generated.
    ("Fixing" recorded simulated data is possible, but we did not
    discuss trying to do this. Both the energy scheme and skew would
    need to be corrected.)
 2. Real REST data from before a year ago is not easy to re-generate and
    so the REST reader needs to be instrumented to reverse the
    approximate scheme and apply the exact scheme when appropriate.
 3. The legacy reconstruction code (versions used to produce REST files
    from reconstruction launches) is still used to reconstruct simulated
    data. Those versions need to be patched to use the exact scheme and
    to output the new REST format.

On a related issue, Beni asked if the scheme he put into HDGeant, where 
secondaries were added back on to the stack so that they can be 
examined, was still present in HDGeant4. Richard has in fact preserved 
that feature.


        Proton timing in the BCAL

This is Issue #179 <https://github.com/JeffersonLab/HDGeant4/issues/179>.

Tegan had a lot of plot ready to go, but we ran out of time. He did show 
a plot of the BCAL shower energy for photons comparing G4, 
no-heavy-light (NHL), G3-HADR1, and G3-HADR4. Surprisingly, NHL showed a 
higher peak value than the others even though light is supposed to be 
suppressed relative to the others. Richard will take a look and will 
update his branch to have all of the latest changes to the master.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20210224/20d6a806/attachment.html>