<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Please find the minutes <a moz-do-not-send="true"
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_September_17,_2019#Minutes">here</a>
      and below.</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 Software Meeting, September 17, 2019, </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> 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="external text"
                  href="https://bluejeans.com/s/97cGP/">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
href="https://halldweb.jlab.org/wiki/index.php/GlueX-Collaboration-Oct-2019"
                    title="GlueX-Collaboration-Oct-2019">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="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2019-September/003758.html">New
                    DB Servers -- HALLDDB-A and HALLDDB-B Online</a>:
                  the new servers were stood up to relieve stress on
                  halldb.jlab.org (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="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 the <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Software_Meeting,_September_3,_2019#Minutes"
                  title="GlueX Software Meeting, September 3, 2019">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="mw-headline"
                  id="Report_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">minutes
                  from the September 10 meeting</a>. Maybe next time.
              </p>
              <h3><span class="mw-headline"
                  id="Reconstruction_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="mw-headline"
                  id="Fixing_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="external text"
                  href="https://github.com/JeffersonLab/halld_recon/issues/111">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="mw-headline"
                  id="Tagger_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="mw-headline"
                  id="Software_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="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2019-September/003761.html">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="mw-headline" id="CCDB_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="external
                  text"
href="https://docs.google.com/presentation/d/1P5mE3SApCmeWv4oNrW58tzeD6zj9neQlr5XORigYCXM/edit?usp=sharing">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="printfooter">
              Retrieved from "<a dir="ltr"
href="https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_September_17,_2019&oldid=94126">https://halldweb.jlab.org/wiki/index.php?title=GlueX_Software_Meeting,_September_17,_2019&oldid=94126</a>"</div>
          </div>
        </div>
      </div>
      <div id="footer" role="contentinfo">
        <ul id="f-list">
          <li id="lastmod"> This page was last modified on 18 September
            2019, at 17:13.</li>
        </ul>
      </div>
    </div>
  </body>
</html>