<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Gluons,</p>
<p>Please find the minutes below and at</p>
<p>
<a class="moz-txt-link-freetext" href="https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_February_9,_2018">https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_February_9,_2018</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">GlueX Offline Meeting, February 9, 2018</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> CMU: </b> Curtis Meyer</li>
<li> <b> FSU: </b> Sean Dobbs</li>
<li> <b> JLab: </b> Alex Austregesilo, Thomas Britton,
Hovanes Egiyan, Mark Ito (chair), David Lawrence, Beni
Zihlmann</li>
<li> <b> Yerevan: </b> Hrach Marukyan</li>
</ul>
<p>There is a <a rel="nofollow" class="external text"
href="https://bluejeans.com/s/oJ0JA/">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/2018-February/003101.html">Reclamation
of halld-scratch volume set</a>. 19 of our tapes are
about to be erased.</li>
<li> <b>New top-level directory: /mss/halld/detectors</b>.
A new tape directory for data related to specific
detectors, e. g., /mss/halld/detectors/DIRC.</li>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2018-February/003106.html">New
sim-recon release: version 2.23.0</a>. This release
includes Simon's newly tuned parameters for track
matching to calorimeter clusters.</li>
<li> <b>New simple email list: online_calibrations</b>.
Sean has created a <a
href="https://halldweb.jlab.org/wiki/index.php/Email_Lists#Simple_Email_Lists"
title="Email Lists">Simple Email List</a> for those
interested in keeping track of the latest calibration
results.</li>
<li> <b>Launches</b>. Thomas caught us up.
<ul>
<li> There is a monitoring launch that will start
soon.</li>
<li> The reconstruction launch with recent software
on Spring 2016 data has started.</li>
<li> Several people are looking at the anomaly that
Beni has identified, visible in some TOF
monitoring plots (though the TOF is blameless).</li>
</ul>
</li>
</ol>
<h3><span class="mw-headline"
id="Review_of_minutes_from_the_January_26_meeting">Review
of minutes from the January 26 meeting</span></h3>
<p>We went over the <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_January_26,_2018#Minutes"
title="GlueX Offline Meeting, January 26, 2018">minutes</a>.
</p>
<h4><span class="mw-headline" id="Optional_Packages">Optional
Packages</span></h4>
<p>In the context of discussing the recent changes with
using the RCDB in the offline software, we started a
more general discussion of whether certain packages, and
RCDB in particular should be optional. David explained
that there are certain packages (among them RCDB, the ET
system) that have been maintained as optional. The
mechanism:
</p>
<ul>
<li>
<ol>
<li> If the "home" environment variable (e. g.,
RCDB_HOME) is not defined, then at build time, the
build system (i. e., SCons) does not include the
corresponding include paths and libraries in the
build commands. No dependence on the package is
built into the resulting code. A warning that this
is happening is printed during the build. This
does not halt the build.</li>
<li> If any program requires the package in
question, then it is built so that when the
program is run, it exits immediately with an error
informing the user that the environment variables
for the missing package needs to be defined and
that package built. Then the build of the program
can be redone.
<ul>
<li> To implement this behavior appropriate
C-preprocessor directives need to be included
in the source code so that the resulting
program has the appropriate behavior depending
on the setting or (non-setting) of the home
environment variable.</li>
</ul>
</li>
</ol>
</li>
</ul>
<p>There was a lot of discussion on whether this is a
useful feature that should be maintained, mainly between
two of us. An incomplete summary:
</p>
<ul>
<li> <b> David </b>. Having the ability to exclude
packages whose functionality is completely irrelevant
to the software builder is very convenient: extraneous
packages need not be built and the resulting disk
footprint of the code is reduced.</li>
<li> <b> Mark </b>. Having this flexibility requires
coding and creates trap doors that code software
builders can fall into. If a needed environment
variable is missing, then the warning at build time
can easily be missed and the error at run time may
leave the user (who may not be the builder) at a loss
as to how to proceed.</li>
</ul>
<p>Mark will put the issue on the agenda of a future
meeting.
</p>
<h4><span class="mw-headline"
id="Release_Management_Thoughts">Release Management
Thoughts</span></h4>
<p>In the course of discussing Sean's presentation from
last time, Thomas brought up the idea of breaking up the
sim-recon repository into two repositories. In a moment
of inspiration he came up with a concept for the split:
one repository for simulation and one for
reconstruction. This would simplify the task of "release
management" (as defined last time). The technical
advantage is that simulation code can be versioned
independently of the reconstruction code. Right now,
Sean has to maintain a
reconstruction-fixed-simulation-changing branch of
sim-recon to get the right behavior. If the two
functions were versioned separately, this
recon-fixed-sim-changing property would be manifest.
</p>
<p>We noted that the two sides (sim and recon) are
functionally closely tied together. The question is the
degree of independence of the development streams on the
two sides. E. g. if drift time in tracking chambers is
improved in simulation, then does the tracking
reconstruction have to change? Likely not, the sim side
can go ahead independently. On the other hand, if there
is reconstruction code that does one thing for real data
and another for simulation, and the simulation is
improved so that unequal treatment is no longer
necessary, then both sides have to change together. In
the latter case it would be easier if both sides were in
the same repository.
</p>
<p>Mark will put the issue on the agenda of a future
meeting.
</p>
<h4><span class="mw-headline"
id="Not-the-TOF_Anomaly_in_Monitoring_Histograms">Not-the-TOF
Anomaly in Monitoring Histograms</span></h4>
<p>Alex noted that the problem first appeared several
months ago when the material maps were changed in the
CCDB. Beni has reported that the most recent version of
the code does not exhibit the problem, so the current
mystery is how the problem could have possibly fixed
itself.
</p>
<h3><span class="mw-headline" id="GlueX_.2B_NERSC">GlueX +
NERSC</span></h3>
<p>David has succeeded in running GlueX reconstruction
jobs on two of the <a rel="nofollow" class="external
text" href="http://www.nersc.gov/">NERSC</a>
supercomputers.
</p>
<ul>
<li> Cori I: Haswell (comparable to the JLab farm)</li>
<li> Cori II: Knight's Landing (KNL)</li>
</ul>
<p>He analyzed two runs on both architectures. See the
results on <a rel="nofollow" class="external text"
href="https://docs.google.com/presentation/d/1FcOhSprdD-YPCZnagvaJl-oicK7y3zoSAuB-Nmo_vSc/edit?usp=sharing">his
slide</a>. He notes that the KNL jobs run 2.4 times
slower than the Haswell even though they are using four
times the number of threads, i. e., ten times slower on
a per thread basis.
</p>
<h3><span class="mw-headline" id="Collaboration_Meeting">Collaboration
Meeting</span></h3>
<p>Sean has put together a nice little session for us on
the <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX-Collaboration-Feb-2018#Saturday_February_24.2C_2018"
title="GlueX-Collaboration-Feb-2018">Collaboration
Meeting agenda</a>.
</p>
<h3><span class="mw-headline" id="SciComp_Meeting_Report">SciComp
Meeting Report</span></h3>
<p>Mark reported items from the Scientific Computing
meeting held Thursday, February 1.
</p>
<ol>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2018-February/003093.html">Change
to fair share allocations...</a>. The change was
discussed at the meeting.</li>
<li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2018-February/003092.html">ENP
consumption of disk space under /work</a>.
<ul>
<li> The second shelf of traditional raid is up and
running. Our work disk quota has been increased to
110 TB from 66 TB.</li>
<li> Hall B migration to the new work disk is
underway. That should free up 85 TB of cache
space. Mark emphasized that Hall D needs more
cache space.</li>
</ul>
</li>
<li> Hall B needs 40 GB per job for the Java virtual
machine. This is causing cores to go idle as nodes are
running in a memory-limited mode.</li>
<li> '<i>New tape drives, playing with four new LT07
drives and four new LT08 drives.</i> They are
planning the upgrade path.</li>
</ol>
<h3><span class="mw-headline" id="AMD_benchmark_results">AMD
benchmark results</span></h3>
<p>Sean has purchased a box with new AMD EPYC processors
and ran benchmarks of hd_root on it. For comparison he
ran the same tests on gluon119 which has Intel Xeon
processors. See <a rel="nofollow" class="external text"
href="https://halldweb.jlab.org/wiki/images/f/fe/Sdobbs_Offline_020918.pdf">his
slide</a> for details and results. Scaling for the two
systems is comparable as the number of threads is
increased, though the AMD processors come a one-third
the price (on the CPU package itself).
</p>
<h3><span class="mw-headline" id="Meeting_on_Containers">Meeting
on Containers</span></h3>
<p>Mark announced a meeting later in the day to discuss
use of containers (Docker, Singularity) in various
computing contexts (NERSC, OSG, JLab farm, personal
laptops). There is a lot of ground to cover here; a
series of meetings is likely.
</p>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>