<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Folks,</p>
<p>Please find the minutes <a moz-do-not-send="true"
href="https://halldweb.jlab.org/wiki/index.php/HDGeant4_Meeting,_February_23,_2021#Minutes">here</a>
and below.</p>
<p>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.<br>
</p>
<p> -- Mark</p>
<p> ________________________________</p>
<p>
</p>
<div id="globalWrapper">
<div id="column-content">
<div id="content" class="mw-body" role="main">
<h2 id="firstHeading" class="firstHeading" lang="en"><span
dir="auto">HDGeant4 Meeting, February 23, 2021, </span><span
class="mw-headline" id="Minutes">Minutes</span></h2>
<div id="bodyContent" class="mw-body-content">
<div id="mw-content-text" dir="ltr" class="mw-content-ltr"
lang="en">
<p>Present: Tegan Beattie, Sean Dobbs, Mark Ito (chair),
Igal Jaegle, Richard Jones, Zisis Papandreou, Justin
Stevens, Simon Taylor, Nilanga Wickramaarachchi, Beni
Zihlmann
</p>
<p>There is a <a rel="nofollow" class="external text"
href="https://bluejeans.com/s/sjAsRH5bnJD/">recording
of this meeting</a> on the BlueJeans site. Log into
the BlueJeans site first to gain access (use your JLab
credentials).
</p>
<h3><span class="mw-headline"
id="Review_of_minutes_from_the_last_meeting">Review of
minutes from the last meeting</span></h3>
<p>We went over the <a
href="https://halldweb.jlab.org/wiki/index.php/HDGeant4_Meeting,_February_9,_2021#Minutes"
title="HDGeant4 Meeting, February 9, 2021">minutes
from February 9</a> without much comment.
</p>
<h3><span class="mw-headline" id="Issues_on_GitHub">Issues
on GitHub</span></h3>
<h4><span class="mw-headline"
id="Incorrect_TAGH_counter_number_assignment">Incorrect
TAGH counter number assignment</span></h4>
<p>This is <a rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/HDGeant4/issues/182">Issue
#182</a>. Richard and Igal introduced the issue and
the proposal. Sean and Justin made significant
contributions to discussion that shaped the proposal.
</p>
<h5><span class="mw-headline" id="The_Issue">The Issue</span></h5>
<ol>
<li> Photon energy (E<sub>γ</sub>) is measured as the
difference between the electron beam energy (E<sub>beam</sub>)
and the post-bremsstrahlung electron energy
corresponding to a particular tagger counter (E<sub>tag</sub>).</li>
<li> E<sub>tag</sub> 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<sub>scale</sub>),
so the entries in the table are all greater than zero
and less than one and each tagger counter has an f<sub>low</sub>
and an f<sub>high</sub>. After E<sub>scale</sub> is
supplied, simple multiplication transforms the table
entries into the desired set of energy bin limits.</li>
<li> E<sub>scale</sub> depends on the tagger magnet
current. In particular, it is independent of the
electron beam energy.</li>
<li> An approximation that we have used in the past in
both simulation and reconstruction is setting E<sub>scale</sub>
equal to E<sub>beam</sub>. This is what MCC tries to
do at the beginning of each run, roughly speaking.
Let's call this the "<b>approximate scheme</b>."</li>
<li> 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<sub>scale</sub>) is different for each run period.</li>
<li> There is no practical reason to use the approximate
scheme, since both E<sub>beam</sub> and E<sub>scale</sub>
are known on a run-by-run basis independently and we
can apply E<sub>γ</sub> = E<sub>beam</sub> - f*E<sub>scale</sub>
unambiguously. Let's call this the <b>exact scheme</b>.
(Yes, not exactly exact, but we are just defining
terms here.)</li>
<li> 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<sub>tag</sub>.
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 <b>skew</b>.</li>
<li> In the asymptotic past, we used the approximate
scheme for both simulation and reconstruction. We also
had the skew in the simulation.</li>
<li> 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.</li>
<li> 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.</li>
<li> mcsmear does not modify these tagger quantities.</li>
<li> The reconstruction (hd_root) outputs its data in
REST format. It reports only the energy, and not the
tagger counter ID.</li>
</ol>
<h5><span class="mw-headline" id="Observations">Observations</span></h5>
<ol>
<li> For the past year or so, we have been using
inconsistent schemes for determining E<sub>tag</sub>
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.</li>
<li> 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.</li>
</ol>
<h5><span class="mw-headline"
id="Philosophy_going_forward">Philosophy going forward</span></h5>
<ol>
<li> Use the exact scheme everywhere.</li>
<li> Communicate tagger energy from program to program
via tagger counter ID. </li>
</ol>
<h5><span class="mw-headline" id="Proposal">Proposal</span></h5>
<ol>
<li> Remove the skew from the simulation.</li>
<li> Change the simulation to use the exact scheme. (The
change is already present in the current
reconstruction.)</li>
<li> Change the REST format to accommodate recording of
the tagger counter ID.</li>
<li> Change the REST reader to use the tagger counter ID
to calculate E<sub>tag</sub>.</li>
</ol>
<h5><span class="mw-headline" id="Implications">Implications</span></h5>
<ol>
<li> 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.)</li>
<li> 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.</li>
<li> 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.</li>
</ol>
<p>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.
</p>
<h4><span class="mw-headline"
id="Proton_timing_in_the_BCAL">Proton timing in the
BCAL</span></h4>
<p>This is <a rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/HDGeant4/issues/179">Issue
#179</a>.
</p>
<p>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.
</p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>