<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Friends,</p>
<p>Please find the minutes below and <a moz-do-not-send="true"
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_May_28,_2019#Minutes">here</a>.</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">Minutes, GlueX Software Meeting, May 28, 2019</span></h2>
<br>
<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> CMU: </b> Naomi Jarvis</li>
<li> <b> FIU: </b> Mahmoud Kamel, Joerg Reinhold</li>
<li> <b> JLab: </b> Shankar Adhikari, Alexander
Austregesilo, Thomas Britton, Mark Dalton, Sean Dobbs,
Mark Ito (chair), David Lawrence, Justin Stevens,
Simon Taylor, Beni Zihlmann</li>
</ul>
<p><br>
There is a <a rel="nofollow" class="external text"
href="https://bluejeans.com/s/QUAf6/">recording of
this 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/2019-May/003635.html">New
version set consistent with recon-2018_08, version
00</a>, as announced May 8.</li>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2019-May/003642.html">MCwrapper
v2.2.0 released</a>. MCwrapper can now sense viable
version sets. The new release uses XROOTD to stream
random triggers. Those files are now kept on the work
disk. Version 2.2.1 is due out soon. The robot will
now submit to the JLab farm when it senses that the
OSG is full.</li>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/jlab-scicomp-briefs/2019q2/000203.html">PBS
to Slurm on June 3rd</a>. This morning SciComp had a
meeting on this. Beni reminded us that either SWIF or
Auger can be used with the new system. Changes under
the new system should be transparent to users, except
for the fact when choosing a custom directory for
standard output and error files, that directory must
be made in advance under slurm.
<ul>
<li> Added in press: during the meeting, SciComp
sent out
[httpd://halldweb.jlab.org/talks/2019/Slurm-rev2.pdf
slides from this morning's presentation].</li>
</ul>
</li>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2019-May/003652.html">A
script for backups of disk files</a>. Mark described
the new script. He has been using it to clean-up
recent congestion on the work disk.</li>
</ol>
<h3><span class="mw-headline"
id="Discussion_of_splitting_analysis_libraries_from_halld_recon">Discussion
of splitting analysis libraries from halld_recon</span></h3>
<p>Justin referred us to <a rel="nofollow"
class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2019-May/003628.html">a
recent discussion on the offline email list</a> and
introduced the topic:
</p>
<ul>
<li> <b>Goal</b>: maintain ability to analyze REST data
produced with fixed halld_recon version using an
updated version of "analysis" libraries currently in
halld_recon.</li>
<li> <b>Proposal</b>: extract ANALYSIS, KINFITTER, and
PID libraries (and required plugins and programs) to a
separate repo halld_ana. </li>
</ul>
<p>Some notes on the discussion:
</p>
<ul>
<li> Fundamental problem: analysis launch data is
created from REST data which was produced with a known
version of halld_recon. The analysis launch itself may
be run with a different version of halld_recon to take
advantage of changes made since the reconstruction
launch. The problem is best illustrated in the case of
Monte Carlo. There, to maintain fidelity with real
data, one should do the reconstruction of the
simulated data with the reconstruction-launch version
of halld_recon, and do analysis with the
analysis-launch version of halld_recon. We have no
mechanism to insure this practice and most users will
not be aware that this is even an issue. The current
version set system has no mechanism to provide two
different versions of a package (halld_recon in this
case), and even if it did the user must know which
hd_root is the right one for reconstruction and which
is the right one for analysis. On top of this, it is
possible to do reconstruction and analysis both
starting from raw (or simulated raw) data. In that the
case "wrong" version of reconstruction or analysis
will be done by construction.</li>
<li> The solution we have been discussing before is the
one Justin proposed: break out some of the libraries
in a separate package that can be version controlled
separately. Then there is a natural distinction
between reconstruction versions and and analysis
versions based on the tagged version of analysis
libraries used. David quickly recognized that there is
fundamental difficulty in this scheme. Currently the
analysis libraries depend on code in the other parts
of halld_recon, and other other parts of halld_recon
depend on the analysis libraries. Since there is no
dependency hierarchy in the code, they cannot be
separated into independent packages, i.e., neither one
can be built first (chicken and egg problem).</li>
<li> Beni pointed out that if it were the case that
analysis could be done only on REST data, then the
necessary dependency hierarchy would obtain and the
analysis packages could be separated. That case could
be enforced by policy. That would break the current
feature where reconstruction and analysis can be done
in the same invocation of hd_root. People were
reluctant to give up this feature.</li>
<li> David thought that the chicken and egg problem
could be solved, but it would require careful
separation of routines into reconstruction libraries,
analysis libraries, and common libraries. Such a clean
separation with the roster of routines in the current
libraries may not be possible.</li>
<li> Justin suggested having two version of halld_recon
in the version sets (version.xml files), one for
reconstruction and one for analysis.</li>
<li> David commented that a system where the analysis
libraries were plug-ins (selected at run-time) that
supersede statically linked versions of the analysis
libraries is possible.</li>
<li> Thomas pointed out that it is possible to modify
MCwrapper to switch from one version set, used for
reconstruction, to another, used for analysis, in a
single job. This does not solve the problem of which
reconstruction version goes with which analysis
launch, and it does no good at all for folks not using
MCwrapper.</li>
<li> Another possibility for MCwrapper jobs is to copy
the analysis-compatible version of hd_root along with
the job on the OSG or elsewhere.</li>
<li> In order to save on disk space with a possibly
exploding number of builds needed (depending on the
solution we settle on) Sean suggested making stripped
down version of halld_recon that exclude the plug-ins
and other appropriately chosen files.</li>
<li> It was noted that having to deal with two complete
version sets is confusing; an independent package
solution is easier to understand.</li>
<li> A method for maintaining the correct correlation of
reconstruction versions and analysis versions should
be a part of any solution.</li>
<li> Alex pointed out the the name of the analysis
launch from which ROOT trees were generated is encoded
in each tree file.</li>
<li> We did not arrive at a solution. Mark encouraged us
to think about one.</li>
</ul>
<h3><span class="mw-headline"
id="Review_of_the_previous_Software_and_HDGeant4_meetings">Review
of the previous Software and HDGeant4 meetings</span></h3>
<p>We went over the <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_April_30,_2019#Minutes"
title="GlueX Software Meeting, April 30, 2019">minutes
from the April 30 Software meeting</a> and <a
href="https://halldweb.jlab.org/wiki/index.php/HDGeant4_Meeting,_May_21,_2019#Minutes"
title="HDGeant4 Meeting, May 21, 2019">those from the
May 21 HDGeant4 meeting</a> without significant
comment.
</p>
<h3><span class="mw-headline"
id="Review_of_recent_issues_and_pull_requests">Review
of recent issues and pull requests</span></h3>
<p>Two issues were reviewed:
</p>
<p><a rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/halld_recon/issues/71">halld_recon:
crash in ST matching #71</a>. This problem is still
causing a huge fraction of monitoring launch jobs to
crash. Work continues on this.
</p>
<p><a rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/halld_recon/issues/166">halld_recon:
Vertex z dependent reconstruction efficiency #166</a>.
Alex recently reported that the vertex position for ρ
events shows structure as a function of z. The effect is
seen in HDGeant, HDGeant4, and real data. This has not
been understood yet.
</p>
<h3><span class="mw-headline"
id="Review_of_recent_discussion_on_the_GlueX_Software_Help_List">Review
of recent discussion on the GlueX Software Help List</span></h3>
<p>We went over <a rel="nofollow" class="external text"
href="https://groups.google.com/forum/#!forum/gluex-software">message
on the help list</a>.
</p>
<p><a rel="nofollow" class="external text"
href="https://groups.google.com/forum/#!topic/gluex-software/WuKlWUsEydo">Matt
and Mark's convo on gluex_install</a> went private at
some point, but in the end the problem was resolved.
</p>
</div>
<div class="printfooter">
Retrieved from "<a dir="ltr"
href="https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_May_28,_2019&oldid=92819">https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_May_28,_2019&oldid=92819</a>"</div>
</div>
</div>
</div>
<div id="footer" role="contentinfo">
<ul id="f-list">
<li id="lastmod"> This page was last modified on 31 May 2019,
at 13:26.</li>
</ul>
</div>
</div>
</body>
</html>