<div dir="ltr">Regarding the infinite variety of use cases for CCDB variation combinations, how about asking Dmitry to implement an easy import/export of constants from a readable text file? So the user can go to ccdb, load constants from calibtime a or variation a, dump it out, load calibtime/variation b, dump it out, combine the two dumps as they see fit, and then upload as variation c. This is really straightforward. Easier than remembering the inheritance rules. Easier for debugging than running repeated instances of ccdb ls table > textfile etc. <div><br><div>Naomi.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2019 at 5:15 PM Mark Ito <<a href="mailto:marki@jlab.org">marki@jlab.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Please find the minutes <a href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_September_17,_2019#Minutes" target="_blank">here</a>
and below.</p>
<p>_________________________________________</p>
<p>
</p>
<div id="gmail-m_-7298917465282973235globalWrapper">
<div id="gmail-m_-7298917465282973235column-content">
<div id="gmail-m_-7298917465282973235content" class="gmail-m_-7298917465282973235mw-body">
<h2 id="gmail-m_-7298917465282973235firstHeading" class="gmail-m_-7298917465282973235firstHeading" lang="en"><span dir="auto">GlueX Software Meeting, September 17, 2019, </span><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Minutes">Minutes</span></h2>
<div id="gmail-m_-7298917465282973235bodyContent" class="gmail-m_-7298917465282973235mw-body-content">
<div id="gmail-m_-7298917465282973235mw-content-text" dir="ltr" class="gmail-m_-7298917465282973235mw-content-ltr" lang="en">
<p>Present:
</p>
<ul>
<li> <b> CMU: </b> Naomi Jarvis</li>
<li> <b> FSU: </b> Sean Dobbs</li>
<li> <b> JLab: </b> Alexander Austregesilo, Mark Ito
(chair), David Lawrence, Simon Taylor, Beni Zihlmann</li>
</ul>
<p>There is a <a rel="nofollow" class="gmail-m_-7298917465282973235external gmail-m_-7298917465282973235text" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__bluejeans.com_s_97cGP_&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Te_hCR4EUlJ6iCDYLJ8Viv2aDOR7D9ZZMoBAvf2H0M4&m=IYKLUuGUrJ7h-sLjihD8cXSGszVsLrdjfKNwhxEqvZk&s=nTojui-vwd5h81bpJECjyria9jHluIv6O8hK9OpmyQQ&e=" target="_blank">recording of his
meeting</a> on the BlueJeans site. Use your JLab
credentials to access it.
</p>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Announcements">Announcements</span></h3>
<ol>
<li> <a href="https://halldweb.jlab.org/wiki/index.php/GlueX-Collaboration-Oct-2019" title="GlueX-Collaboration-Oct-2019" target="_blank">Collaboration
Meeting</a>: Sean has proposed a list of speakers
for the Offline Session on Thursday. Alex will
substitute for David and give a status of data
processing.</li>
<li> <a rel="nofollow" class="gmail-m_-7298917465282973235external gmail-m_-7298917465282973235text" href="https://mailman.jlab.org/pipermail/halld-offline/2019-September/003758.html" target="_blank">New
DB Servers -- HALLDDB-A and HALLDDB-B Online</a>:
the new servers were stood up to relieve stress on
<a href="http://halldb.jlab.org" target="_blank">halldb.jlab.org</a> (our main database server) from farm
jobs. Testing is still in progress but users are
welcome to try it out.</li>
<li> <b>No online compression this Fall</b>. David has
discussed the issue with Graham and they agree that
compression of raw data is not ready for the November
run. In addition using ramdisk on the front end,
improvements in the Data Transfer Node (for off-site
transfers), and expansion of disk space at JLab all
reduce the need for immediate relief on data size.</li>
</ol>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Review_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,_September_3,_2019#Minutes" title="GlueX Software Meeting, September 3, 2019" target="_blank">minutes
from September 3</a>.
</p>
<p>David gave us an update on NERSC and PSC.
</p>
<ul>
<li> At NERSC, batch 3 of the Fall 2018 data
reconstruction is finished. 80% of the output has been
brought back to the Lab.</li>
<li> At the Pittsburgh Supercomputing Center (PSC) there
is a steady rate of about 300 jobs a day, slower than
NERSC, but with fewer job failures. It is not clear
why the pace is so slow.</li>
<li> At NERSC, Perlmutter will be coming on line next
year with an attendant large increase in computing
capacity.</li>
<li> The XSEDE proposal at PSC has been approved with
5.9 million units. October 1 is the nominal start
date. Note that our advance award was 850 thousand
units.</li>
</ul>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Report_from_the_last_HDGeant4_Meeting">Report from
the last HDGeant4 Meeting</span></h3>
<p>We forgot to go over the <a href="https://halldweb.jlab.org/wiki/index.php/HDGeant4_Meeting,_September_10,_2019#Minutes" title="HDGeant4 Meeting, September 10, 2019" target="_blank">minutes
from the September 10 meeting</a>. Maybe next time.
</p>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Reconstruction_Software_for_the_upgraded_Time-of-Flight">Reconstruction
Software for the upgraded Time-of-Flight</span></h3>
<p>Sean went through and made the needed changes. The
DGeometry class was modified to load in the geometry
information. The new DTOFGeometry class was changed to
present the info in a more reasonable way. There were
places where geometry parameters where hard-coded. These
were changed to use the information from the
CCDB-resident HDDS files. The process benefited from the
structure where the DGeometry class parses the HDDS XML
and the individual detector geometry classes turn that
information into useful parametrizations.
</p>
<p>Right now hits are not showing up in the simulation
(HDGeant4). Fixing this is the next task.
</p>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Fixing_Crashes_When_Running_over_Data_with_Multiple_Runs">Fixing
Crashes When Running over Data with Multiple Runs</span></h3>
<p>Sean described his fix of a long standing problem,
first reported by Elton Smith, where the ReactionFilter
crashes when run over data that contains multiple runs.
This closes <a rel="nofollow" class="gmail-m_-7298917465282973235external gmail-m_-7298917465282973235text" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_issues_111&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Te_hCR4EUlJ6iCDYLJ8Viv2aDOR7D9ZZMoBAvf2H0M4&m=IYKLUuGUrJ7h-sLjihD8cXSGszVsLrdjfKNwhxEqvZk&s=JlmVIVFi35Zqqh8xVTmtH5aPLYcLWpmizdw7sIcbbNs&e=" target="_blank">halld_recon
issue #111</a>. In particular, the DParticleID class
assumed the that run number never changes. Necessary
refresh of constants from the CCDB on run number
boundaries was thus never done.
</p>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Tagger_Counter_Energy_Assignment_Bug">Tagger
Counter Energy Assignment Bug</span></h3>
<p>Beni brought to our attention an issue that was
discussed at the last Beamline Meeting. Currently,
tagger energies are set as a fraction of the endpoint
energy. But since the electron beam energy can change
from run to run, albeit by a small amount, the reported
energy of a particular tagger counter will change when
the tagged electron energy bin is really determined by
the strength of the tagger magnet field. Richard Jones
is working on a proposal on how this should be fixed.
</p>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235Software_Versions_and_Calibration_Constant_Compatibility">Software
Versions and Calibration Constant Compatibility</span></h3>
<p>Sean led us through an issue he described in <a rel="nofollow" class="gmail-m_-7298917465282973235external gmail-m_-7298917465282973235text" href="https://mailman.jlab.org/pipermail/halld-offline/2019-September/003761.html" target="_blank">an
earlier email</a> to the Offline List. The basic issue
is that older versions of mcsmear are not compatible
with recent constants used in smearing the FCAL. We
discussed the issue and concluded that the problem was
changing the meaning of columns in the table, rather
than creating a new calibration type with the new
interpretation. Because this situation, the software has
to know which interpretation is correct for a given set
of constants. Old software versions are not instrumented
to do so, of course. If the constants are under a
different type, the then the software will know which
type is it using and do the right thing. And old
software, only knowing about the old type will do the
right thing as well.
</p>
<p>Sean is thinking about how we will address this going
forward.
</p>
<h3><span class="gmail-m_-7298917465282973235mw-headline" id="gmail-m_-7298917465282973235CCDB_Ancestry_Control">CCDB
Ancestry Control</span></h3>
<p>Mark presented a set of issues that arise with CCDB 2.0
(coming soon). See <a rel="nofollow" class="gmail-m_-7298917465282973235external gmail-m_-7298917465282973235text" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_presentation_d_1P5mE3SApCmeWv4oNrW58tzeD6zj9neQlr5XORigYCXM_edit-3Fusp-3Dsharing&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=Te_hCR4EUlJ6iCDYLJ8Viv2aDOR7D9ZZMoBAvf2H0M4&m=IYKLUuGUrJ7h-sLjihD8cXSGszVsLrdjfKNwhxEqvZk&s=lT7k_ydrjM6cwgOxuCzJxCaz3XmkANVp84HXJQjfhKk&e=" target="_blank">his
slides</a> for all of the dirty details.
</p>
<p>In CCDB 1.x we can "freeze" calibration constants in
time by setting a "calib-time" for the system to use.
All calibration changes made after that time will be
ignored. Because of the hierarchical structure of
calibration "variations" there is a valid use case where
the user may want constants at the level of the named
variation to float, but freeze the constants coming from
variations higher in the hierarchy. This use case is not
supported under CCDB 1.x, but is provided for in CCDB
2.0. The implementation provides a rich set of choices
for freezing (or not freezing) variations in the
hierarchy. Too rich in fact. The discussion was about
how to limit the scope of what can be done so users are
presented with an understandable, tractable set of
options. There was a lot of discussion. See the
recording if interested.
</p>
<p>No final decision was made, but at least by the end of
the meeting everyone was aware of the nature of the
problem.
</p>
</div>
<div class="gmail-m_-7298917465282973235printfooter">
Retrieved from "<a dir="ltr" href="https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_September_17,_2019&oldid=94126" target="_blank">https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_September_17,_2019&oldid=94126</a>"</div>
</div>
</div>
</div>
<div id="gmail-m_-7298917465282973235footer">
<ul id="gmail-m_-7298917465282973235f-list">
<li id="gmail-m_-7298917465282973235lastmod"> This page was last modified on 18 September
2019, at 17:13.</li>
</ul>
</div>
</div>
</div>
_______________________________________________<br>
Halld-offline mailing list<br>
<a href="mailto:Halld-offline@jlab.org" target="_blank">Halld-offline@jlab.org</a><br>
<a href="https://mailman.jlab.org/mailman/listinfo/halld-offline" rel="noreferrer" target="_blank">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></blockquote></div>