HDGeant4 Meeting, February 23, 2021
Tuesday, February 23, 2021
3:00 pm EST
BlueJeans: 968 592 007
- Review of minutes from the last meeting (all)
- Issues on GitHub
- Pull Requests on GitHub
- Action Item Review
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 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 without much comment.
Issues on GitHub
Incorrect TAGH counter number assignment
This is Issue #182. Richard and Igal introduced the issue and the proposal. Sean and Justin made significant contributions to discussion that shaped the proposal.
- Photon energy (Eγ) is measured as the difference between the electron beam energy (Ebeam) and the post-bremsstrahlung electron energy corresponding to a particular tagger counter (Etag).
- Etag 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 (Escale), so the entries in the table are all greater than zero and less than one and each tagger counter has an flow and an fhigh. After Escale is supplied, simple multiplication transforms the table entries into the desired set of energy bin limits.
- Escale depends on the tagger magnet current. In particular, it is independent of the electron beam energy.
- An approximation that we have used in the past in both simulation and reconstruction is setting Escale equal to Ebeam. This is what MCC tries to do at the beginning of each run, roughly speaking. Let's call this the "approximate scheme."
- 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 Escale) is different for each run period.
- There is no practical reason to use the approximate scheme, since both Ebeam and Escale are known on a run-by-run basis independently and we can apply Eγ = Ebeam - f*Escale unambiguously. Let's call this the "exact scheme." (Yes, not exactly exact, but we are just defining terms here.)
- 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 Etag. 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."
- In the asymptotic past, we used the approximate scheme for both simulation and reconstruction. We also had the skew in the simulation.
- 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.
- 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.
- mcsmear does not modify these tagger quantities.
- The reconstruction (hd_root) outputs its data in REST format. It reports only the energy, and not the tagger counter ID.
- For the past year or so, we have been using inconsistent schemes for determining Etag 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.
- 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
- Use the exact scheme everywhere.
- Communicate tagger energy from program to program via tagger counter ID.
- Remove the skew from the simulation.
- Change the simulation to use the exact scheme. (The change is already present in the current reconstruction.)
- Change the REST format to accommodate recording of the tagger counter ID.
- Change the REST reader to use the tagger counter ID to calculate Etag.
- 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.)
- 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.
- 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.
Tegan had a lots 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.