<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Friends,<br>
<br>
Please find the minutes below and at
<a class="moz-txt-link-freetext" href="https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_August_19,_2015#Minutes">https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_August_19,_2015#Minutes</a>
.<br>
<br>
-- Mark<br>
_____________________________________________________<br>
<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, August 19, 2015, </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>FIU</b>: Mahmoud Kamel</li>
<li> <b>FSU</b>: Brad Cannon, Aristeidis Tsaris</li>
<li> <b>JLab</b>: Alex Barnes, Amber Boehnlein, Mark
Ito (chair), David Lawrence, Paul Mattione, Elton
Smith, Nathan Sparks, Justin Stevens, Simon Taylor,
Beni Zihlmann</li>
<li> <b>NU</b>: Sean Dobbs</li>
<li> <b>UConn</b>: Richard Jones</li>
</ul>
<h3><span class="mw-headline" id="Announcements">Announcements</span></h3>
<ol>
<li> The <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2015-August/002122.html"><code>build_scripts</code>
repository moved to GitHub</a> earlier this week. On
a related policy note, we decided that if a repository
is maintained by a single person, then we can skip the
pull-request/merge-by-someone-else procedure and allow
the maintainer to push directory to the repository.</li>
<li> Kei Moriya posted links from last week's
calibration meeting on Offline Monitoring (see below).
Paul mentioned that the last launch went smoothly and
Kei is feeding back suggestions for SWIF to Chris
Larrieu and has written a GlueX-oriented SWIF wrapper,
<code>hdswif</code>. The next launch will be next
week.
<ul>
<li> <a rel="nofollow" class="external text"
href="https://halldweb.jlab.org/wiki/images/b/b1/2015-08-12-offline_monitoring.pdf">Status
report</a></li>
<li> <a rel="nofollow" class="external text"
href="https://halldweb.jlab.org/wiki/images/3/3a/Hdswif.pdf">hdswif</a></li>
</ul>
</li>
</ol>
<h3><span class="mw-headline"
id="Review_of_minutes_from_August_5">Review of minutes
from August 5</span></h3>
<p>We went over <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_August_5,_2015#Minutes"
title="GlueX Offline Meeting, August 5, 2015">the
minutes from last time</a>. There was no significant
discussion.
</p>
<h3><span class="mw-headline"
id="Software_for_Correcting_for_Pedestal_Drifts">Software
for Correcting for Pedestal Drifts</span></h3>
<p>Elton raised the issue of how to apply pedestal
corrections that occur on a time scale smaller than a
single run. There are several online and offline aspects
to the problem and the method is not settled on either
side. We discussed several aspects of the problem.
</p>
<ul>
<li> The pedestals have been observed to drift
significantly on a scale of a few hours. We might need
to change pedestal a values on a 10 minute time scale.</li>
<li> The CCDB is currently set up to handle constants on
a run-by-run basis. The conceptual design for
event-dependent constants has been worked out, but
nothing has been coded.</li>
<li> JANA already has the hooks for obtaining
event-dependent constants from the CCDB when/if that
functionality comes along.</li>
<li> There is a potential problem with constants that
apply to event ranges since with multiple threads not
every thread will cross a given event boundary at the
same time. This could be solved by using the "event
barriers" David recently introduced in JANA. This
mechanism requires that all threads synchronize on a
designated point in the input data stream, each thread
not going past it until all threads have caught up.
Event barriers can be triggered without dependence on
special event types in the data stream. The
development of this mechanism was originally motivated
by the idea of using data from EPICS events in the
data stream in the reconstruction.</li>
<li> There may be a possible bias in pedestals since
read-out is only done for hits; there will always be a
hit nearby in time when obtaining pedestals.</li>
<li> Depending on the online scheme, we may obtain
pedestals on an event-by-event basis, or average them
over a range of events. In the former case,
calibration constants are not needed; the pedestals
are embedded in the event stream.</li>
</ul>
<p>We did not decide on a definite action plan. The
character of the online solution is still evolving and
that will largely dictate the offline approach.
</p>
<h3><span class="mw-headline" id="Data_Challenge_3_update">Data
Challenge 3 update</span></h3>
<p>Mark has produced about half of 5000 input files and
written them to the tape library. The files are 10 GB
and contain about 430 k events each. Each file takes
about a day of CPU time to produce. These files have
also been reconstructed in a practice run on the data.
Processing is ongoing.
</p>
<h3><span class="mw-headline"
id="Spring_2015_Commissioning_Simulations">Spring 2015
Commissioning Simulations</span></h3>
<p>Mark reported that all of the <a
href="https://halldweb.jlab.org/wiki/index.php/Spring_2015_Commissioning_Simulations"
title="Spring 2015 Commissioning Simulations">30,600
jobs</a> are complete, both event generation and
reconstruction. The "raw" data (mcsmear output, HDDM
format), and the REST files have been archived to the
tape library and are now available on the cache disk
under /cache/mss/halld/detcom/02/smeared and rest
respectively.
</p>
<p>Sean mentioned that Elton was interested in simulations
using the latest version of the simulation and
reconstruction (more recent than what we used). He also
cautioned that the new start counter monitoring package
does not have correspondingly new constants for
simulated data yet. Mark will look into tagging a
release with the latest code save the start counter
plugin.
</p>
<h3><span class="mw-headline" id="Geant4_Update">Geant4
Update</span></h3>
<p>Richard reported on his detailed comparison of tracks
between Geants 3 and 4. The results from a sample of 2:
</p>
<ol>
<li> track 1: perfect agreement for about 750 steps</li>
<li> track 2: spectacular disagreement</li>
</ol>
<p>He traced the discrepancy to a feature implemented in
Geant 3 where the magnetic field was turned off on the
calorimeters to speed up shower development. This, in
fact, is where most of the simulation time is spent. He
found a subtle bug having to do with how the magnetic
field is inherited from mother volumes in Geant 4 which
needs to be addressed.
</p>
<p>He will look at the cost in Geant 4 of leaving the
field on and report to the group. He was hopeful that
the CPU time penalty would not be too bad and we can run
with the field on the calorimeters. This mode would be
important for charged particles punching through the
calorimeter, of particular interest for the charge pion
polarizability experiment.
</p>
<p>He is also working to complete the class that allows
each straw to declare its number.
</p>
<p>Richard also needs to test the Geant4 multi-threaded
tracking facility.
</p>
<p>David will work on implementing sensitive detectors
along the lines used for the CPP.
</p>
<h3><span class="mw-headline"
id="Hall_D_Package_Manager_Update">Hall D Package
Manager Update</span></h3>
<p>Nathan gave us an update on the current state of the
project for facilitating builds of GlueX software. See <a
rel="nofollow" class="external text"
href="https://halldweb.jlab.org/talks/2015/hdpm-update.pdf">his
slides</a> for details of his presentation. The major
changes since his last report to the group are (from
slide 10):
</p>
<ul>
<li> Name change to hdpm from HDBuildManager </li>
<li> hdpm command user-interface </li>
<li> Check dependencies within listed packages </li>
<li> Control build commands with "commands.txt" </li>
<li> Support for geant4 and amptools </li>
<li> Setup scripts for 64-bit Linux and Mac OS X</li>
</ul>
<p>He urged us to give it a try. An extensive <a
rel="nofollow" class="external text"
href="https://github.com/JeffersonLab/hdpm">README</a>
is available on GitHub.
</p>
<h3><span class="mw-headline"
id="Flash_ADC_Pulse_Processing_Emulation:_who_is_doing_what.3F">Flash
ADC Pulse Processing Emulation: who is doing what?</span></h3>
<p>David described some of the current issues with
emulation of the firmware algorithm used in the Flash
ADCs.
</p>
<ol>
<li> The current code does not reproduce the results of
the firmware exactly.</li>
<li> Parameters for the algorithm are different for
different detectors. There is not mechanism at present
to retrieve these parameters at reconstruction time.</li>
<li> There are several people working on the problem,
including Mike Staib, Mark Dalton and Kei.</li>
</ol>
<p>To solve the second issue, in addition to access to the
parameters themselves, one requires access to the
translation tables to identify the relevant detector.
</p>
<p>David will be calling a meeting to bring interested
parties together, discuss the needed infrastructure, and
try to avoid duplication of effort.
</p>
<h3><span class="mw-headline"
id="Who_is_responsible_for_deleting_Git_branches.3F">Who
is responsible for deleting Git branches?</span></h3>
<p>The sim-recon Git repository is starting to accumulate
a significant number of branches from code improvements
pushed upstream. Most can be deleted, but we have not
assigned responsibility for doing so within the group.
</p>
<p>Mark proposed a policy where the developer that
originally pushed the changes is responsible for
deleting branches after merge. There was some discussion
about whether having "person doing the merge does the
delete" instead. That might be more efficient, but Mark
argued that the person pushing the changes was in the
best position to judge. In the end we decided to try
Mark's proposal.
</p>
<h3><span class="mw-headline"
id="Default_for_builds:_with_debug_symbols_or_without.3F">Default
for builds: with debug symbols or without?</span></h3>
<p>Nathan presented <a rel="nofollow" class="external
text"
href="https://halldweb.jlab.org/talks/2015/debug_symbols.pdf">results
of studies</a> on performance of both the GCC and the
Clang C++ compilers comparing performance with and
without the production of debugging symbols. The symbols
are not only important for running the debugger, but
give line number information on crashes when binaries
are run normally. Compilation is slowed significantly
and the disk footprint is an order of magnitude bigger
with the symbols.
</p>
<p>The current default is to build with debugging symbols.
Although Nathan proposed changing the default, the group
endorsed David's original judgment that having symbols
is worth the cost.
</p>
<p>We also talked a bit about Clang. It seems to perform
marginally better than GCC. One major advantage that
people reported is that the error messages produced at
compiler time are much easier to understand, no small
advantage. Clang also seems to be available as a package
in most common Linux distributions.
</p>
<h3><span class="mw-headline" id="Action_Item_Review">Action
Item Review</span></h3>
<p>We did not get to this; the room was emptying quickly
at this point. ;-)
</p>
</div>
<div class="printfooter">
Retrieved from "<a dir="ltr"
href="https://halldweb.jlab.org/wiki/index.php?title=GlueX_Offline_Meeting,_August_19,_2015&oldid=69473">https://halldweb.jlab.org/wiki/index.php?title=GlueX_Offline_Meeting,_August_19,_2015&oldid=69473</a>"</div>
</div>
</div>
</div>
<div id="footer" role="contentinfo">
<ul id="f-list">
<li id="lastmod"> This page was last modified on 21 August
2015, at 10:30.</li>
</ul>
</div>
</div>
<br>
</body>
</html>