<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,_March_3,_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, March 3, 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:
</p>
<ul>
<li> <b> FSU: </b> Sean Dobbs</li>
<li> <b> JLab: </b> Alex Austregesilo, Hovanes Egiyan,
Mark Ito (chair), Igal Jaegle, David Lawrence, Keigo
Mizutani, Andrew Schick, Beni Zihlmann</li>
<li> <b> ODU: </b> Nilanga Wickramaarachchi</li>
</ul>
<p>There is a <a rel="nofollow" class="external text"
href="https://bluejeans.com/s/C9Djj">recording of his
meeting</a> on the BlueJeans site. Use your JLab
credentials to access it.
</p>
<h3><span class="mw-headline" id="Announcements">Announcements</span></h3>
<ol>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2020-February/003928.html">/volatile/halld
moving to a new Lustre system</a> Files on the old
partition will be deleted tomorrow.</li>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2020-February/003934.html">Deprecating
DIST in favor of HALLD_VERSIONS for version.xml
files</a>. Currently existing version set files will
remain in DIST until May 1.</li>
</ol>
<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 <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_February_18,_2020#Minutes"
title="GlueX Software Meeting, February 18, 2020">the
minutes from February 18</a>.
</p>
<ul>
<li> The plan to delete some old CDC tables from the
CCDB <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2020-February/003913.html">went
slightly awry</a>. We had to restore from backup and
scuttle the plan.</li>
<li> The <a rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/rcdb/issues/86">issue
on having the collaboration in general maintain data
integrity</a> on the RCDB has been submitted.</li>
<li> <a rel="nofollow" class="external text"
href="https://groups.google.com/forum/#!topic/gluex-software/HDDMbBfBqVA">Dakota
Christian's issue with MC</a> turned out to be
sensitivity to the order of decays in genr8.</li>
</ul>
<h3><span class="mw-headline"
id="recon.xml_files_matching_between_MC_and_data_analysis_launches">recon.xml
files matching between MC and data analysis launches</span></h3>
<p>We discuss an issue raised in <a rel="nofollow"
class="external text"
href="https://groups.google.com/forum/#!topic/gluex-software/KV195ZFLFAg">this
question to the software help group</a> from Nacer
Hamdi.
</p>
<p>The fundamental complication raised is that to do
reconstruction we rely on a particular version of
halld_recon. Subsequent Monte Carlo simulation therefore
need to use the same version of halld_recon to be
consistent. On the other hand, analysis launches on REST
data produced by the reconstruction launches produce
ROOT trees using the analysis library (among other
packages) also provided by halld_recon. So root tree
creation for simulation, to be consistent, needs to use
this second version of halld_recon. This was first <a
rel="nofollow" class="external text"
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_May_28,_2019#Discussion_of_splitting_analysis_libraries_from_halld_recon">discussed
back in May of last year</a>. The solution we settled
on was to create a new XML files
(version_correlations.xml) that would identify pairs of
halld_recon versions (actually version set files) so
that the appropriate versions could be deployed on Monte
Carlo.
</p>
<ul>
<li> Nacer's question pointed out that not all useful
version set pairs have been recorded and built.</li>
<li> Mark pointed out that the implementation currently
in MCwrapper-bot to guide the user to a choice of
consistent versions is complicated. It would be
difficult to describe at a level that can be
reproduced easily by non-experts.</li>
<li> Mark further pointed out the the correlation XML
files was a stop-gap solution. It was easy to
implement and works, but was not necessarily the
"best" solution.</li>
<li> Mark's suggestion is that we go back and revisit
the idea of breaking out the analysis libraries from
halld_recon. Recall that from that discussion last
year, this is not as easy as it might seem on the
surface; there are in fact many libraries involved in
the overlap between reconstruction and analysis, not
just the analysis library.</li>
<li> Alex was skeptical about whether further
deconstruction of halld_recon would result in a
simpler system since there would still be libraries
used in both reconstruction and analysis and so the
two-version problem would still obtain.</li>
<li> Alex proposes that the choice of MCwrapper be based
on the version set of the analysis launch that is
being simulated. Then the choice of both halld_recon
versions should be unambiguous.</li>
<li> Sean pointed out that is all of the information
about what versions were used for which launches is
stored in a database, an interface should be able to
pick out correct pairs of versions sets.</li>
<li> Alex has spoken to Thomas Britton about
implementing the "pick-an-analysis-launch" approach
for MCwrapper-bot. It was alleged that Thomas has
agreed to work on it (someday).</li>
</ul>
<h3><span class="mw-headline"
id="Review_of_recent_issues_and_pull_requests">Review
of recent issues and pull requests</span></h3>
<p>We went over several of the issue pages. See the list
above in the agenda.
</p>
<p>In the course of the review, Sean raised the issue of
access control for the CCDB. We have seen mistakes go
into the default variation of the CCDB on the master
replica on the server on hallddb.jlab.org. Most of the
time these have been caught and corrected promptly, but
there is an example where a non-optimal set of constants
was used for production reconstruction. Approaches:
</p>
<ol>
<li> Sean advocates creating a white list so that only
certain users can write to the default variation on
the master.
<ul>
<li> [added in press] This was not in the original
implementation because it would prevent users from
creating private variations on the database
server, private variation that could be used for
testing and learning. To maintain that capability
an custom access control system would have to be
coded and managed.</li>
</ul>
</li>
<li> David floated the idea of having a the master on a
separate server altogether. This server could be
configured to require a password when connecting.</li>
</ol>
<p>Mark agreed to talk to Dmitry Romanov again to review
what hooks are already available and get his ideas on an
approach.
</p>
</div>
<div class="printfooter">
Retrieved from "<a dir="ltr"
href="https://halldweb.jlab.org/wiki/index.php?title=Gluex_Software_Meeting,_March_3,_2020&oldid=97134">https://halldweb.jlab.org/wiki/index.php?title=Gluex_Software_Meeting,_March_3,_2020&oldid=97134</a>"</div>
</div>
</div>
</div>
<div id="footer" role="contentinfo">
<ul id="f-list">
<li id="lastmod"> This page was last modified on 9 March 2020,
at 18:06.</li>
</ul>
</div>
</div>
</body>
</html>