<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/GlueX_Software_Meeting,_April_14,_2020#Minutes">here</a>
and below.</p>
<p> -- Mark</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">GlueX Software Meeting, April 14, 2020, </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: Alex Austregesilo, Edmundo Barriga, Thomas
Britton, Mark Dalton, Sean Dobbs, Sergey Furlatov,
Hovanes Egiyan, Mark Ito (chair), Igal Jaegle, Naomi
Jarvis, David Lawrence, Hao Li, Keigo Mizutani, Justin
Stevens, Simon Taylor, Beni Zihlmann
</p>
<h3><span class="mw-headline" id="Announcements">Announcements</span></h3>
<p><a rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/gluex_MCwrapper/releases/tag/v2.4.0">MCwrapper:
Schoolly D release</a>.
</p>
<ul>
<li> Includes some changes to deal with the CCDB saga.
No recent complaints about server overloading from
MCwrapper.</li>
<li> Added option to use Slurm at JLab directly.
Sub-option to use Slurm with a container.</li>
<li> Sean's fixes to skipping events seems to have
worked.</li>
<li> N.B., run 41106 has a corrupt random trigger file.</li>
</ul>
<h3><span class="mw-headline"
id="Review_of_Minutes_from_the_Last_Software_Meeting">Review
of Minutes from the Last Software Meeting</span></h3>
<p>We went over the <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_March_31,_2020#Minutes"
title="GlueX Software Meeting, March 31, 2020">minutes
from March 31</a>.
</p>
<ul>
<li> Mark I. got a prescription for how to generate a
sample database for CCDB 2.0 from Dmitry Romanov.</li>
<li> Thomas reported that he wrote a wiki page on <a
href="https://halldweb.jlab.org/wiki/index.php/Instructions_for_Generating_Simulations"
title="Instructions for Generating Simulations">Instructions
for Generating Simulations</a> as requested.</li>
</ul>
<h3><span class="mw-headline"
id="Random_number_seeds_and_the_DL1MCTrigger_factory">Random
number seeds and the DL1MCTrigger_factory</span></h3>
<p>Mark Dalton reported an issue with warnings he gets
when running certain generators.
</p>
<pre>WARNING: Random seeds passed to DRandom2::SetSeeds have
forbidden values:
seed = 1 (must be at least 2)
seed1 = 1064317597 (must be at least 8)
seed1 = 48 (must be at least 16)
See comments in source for TRandom2::SetSeed(int)
The seeds will all be adjusted to be in range.
</pre>
<p>The problem has been traced to
libraries/TRIGGER/DL1MCTrigger_factory.cc. The code is
fro Sascha Somov, in 2017. Richard prescribed a simple
solution that does not really use the random number
generator in the way it is supposed to be used, but will
suppress warnings. There is also a "proper" solution,
but that was a bit hard to glean from the email exchange
Mark showed.
</p>
<p>There is the question of whether there should be any
random number generation in the reconstruction libraries
at all. Our philosophy is to put any detector noise in
mcsmear so that reconstruction, even if Monte Carlo
data, is reproducible.
</p>
<p>In the end we did come to a conclusion on a path
forward. Choices are (a) leave it alone and ignore the
warnings (b) implement the simple solution and suppress
the warnings (c) fix it properly in
DL1MCTrigger_factory.cc or (d) move the random noise
generation to mcsmear. We may have to discuss this
further.
</p>
<h3><span class="mw-headline"
id="Missing_hypothesis_timing">Missing hypothesis
timing</span></h3>
<p>Justin has made a change (<a rel="nofollow"
class="external text"
href="https://github.com/JeffersonLab/halld_recon/pull/346">Pull
Request #346</a>) that improved the resolution of
time-of-arrival for kaons at the DIRC by referencing it
to a fast detector like the Time-of-Flight. This had a
side-effect of also changing timing for protons, causing
a drop in proton yield that Alex noticed in the in the
reconstruction tests. Justin submitted a fix (<a
rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/halld_recon/pull/353">Pull
Request #353</a>) that left the protons alone while
improving kaon time.
</p>
<p>[The secretary refers the reader to Justin, Simon, and
Alex for a more complete description of the problem and
solution.]
</p>
<h3><span class="mw-headline" id="Python_2_vs._Python_3">Python
2 vs. Python 3</span></h3>
<p>Mark I. described recent work in getting a successful
build of our software stack on Fedora 31. This
distribution has Python 3 as the default and therefore
demonstrates explicitly some of the problems we will
have in making the transition from Python 2. His
approach however was to make minimal changes so that our
build system would explicitly choose to run Python 2
rather than going along with the default. Fedora comes
with the packages to allow this choice in all cases of
interest without having to build custom versions of
Python or of Python-based code. He found a solution that
builds everything, from scratch, and whose explicit
Python 2 choices are supported on RHEL7. More testing is
needed but he will submit a pull request in the next
week or so. See <a rel="nofollow" class="external text"
href="https://docs.google.com/presentation/d/13B8vi7qPFPDzz-9J599iBURg8AJ81GjOh2ZZIrJn0zc/edit?usp=sharing">his
slides</a> for details.
</p>
<p>One piece that did not respond to this treatment is the
set of Python modules built by halld_recon. These
facilitate Python handling of HDDM files. They build
under Python 3, but forcing a Python 2 build on Fedora
is more complicated than for other components. (Note
that on a Python-2-default system, they are building and
will continue to build without modification.) The way
that the Python module building is incorporated into the
halld_recon SCons build system is complicated. This
motivated him to look at splitting out the
non-reconstruction-related pieces of the HDDM system
from halld_recon, where the system would be simpler to
work on. In addition, HDDM could then be versioned
independently from changes in our reconstruction
algorithms. HDDM is currently one of the major
components inside of halld_recon that causes halld_recon
to be a prerequisite for halld_sim and hdgeant4. An
independent HDDM build would be a big first step in
breaking the dependency, one that has been causing us a
lot of fuss and bother over the years. Again, see his
slides for details.
</p>
<h3><span class="mw-headline"
id="hd_root_not_filling_the_skims">hd_root not filling
the skims</span></h3>
<p>Just before the meeting started Hao <a rel="nofollow"
class="external text"
href="https://groups.google.com/forum/#!msg/gluex-software/9XS9CTgYRbY/dpf0suBYAAAJ">posted
a question</a> to the Software Help List on a crash he
was seeing where the run number assigned during a
simulation run depended on the node he was running on at
CMU. We did not come to any conclusions about the source
of his problem.
</p>
<p>[Added in press: after the meeting and over the next
three days (48 posts) there was a lot of discussion on
this topic. In summary, we will be changing the way that
the HDDM reader recognized the flavor of HDDM it is
dealing with.]
</p>
</div>
<div class="printfooter">
Retrieved from "<a dir="ltr"
href="https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_April_14,_2020&oldid=98238">https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_April_14,_2020&oldid=98238</a>"</div>
</div>
</div>
</div>
<div id="footer" role="contentinfo">
<ul id="f-list">
<li id="lastmod"> This page was last modified on 17 April
2020, at 14:46.</li>
</ul>
</div>
</div>
</body>
</html>