<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>People,</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,_January_10,_2018#Minutes">https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_January_10,_2018#Minutes</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, January 10, 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> FIU </b>: Mahmoud Kamel, Joerg Reinhold</li>
                <li> <b> Glasgow </b>: Peter Pauli</li>
                <li> <b> JLab: </b>: Alex Austregesilo, Amber
                  Boehnlein, Thomas Britton, Mark Ito (chair), David
                  Lawrence, Simon Taylor </li>
                <li> <b> Yerevan </b>: Hrach Marukyan</li>
              </ul>
              <p>There is a <a rel="nofollow" class="external text"
                  href="https://bluejeans.com/s/q6j0w/">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/2017-December/003047.html">New
                    simulation branch</a>. Sean's email identifies the
                  branch we should be using in simulation to used with
                  the latest reconstruction launch.</li>
                <li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2018-January/003051.html">MCwrapper
                    1.12</a>. Thomas has release a new version. It
                  supports submission to the Open Science Grid. Changes
                  coming in the next release:
                  <ul>
                    <li> Fix to a problem identified by Jon Zarling
                      having to do with RCDB on RHEL6/CentOS6.</li>
                    <li> Fix to a problem pointed out by Nacer Hamdi
                      having to do with amorphous radiator runs.</li>
                  </ul>
                </li>
              </ol>
              <h3><span class="mw-headline"
                  id="Review_of_minutes_from_the_last_meeting">Review of
                  minutes from the last meeting</span></h3>
              <p>We looked at the <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_December_13,_2017#Minutes"
                  title="GlueX Offline Meeting, December 13, 2017">minutes
                  of the meeting on December 13</a>.
              </p>
              <p>We noted that we still need a tagged version of CCDB.
              </p>
              <h3><span class="mw-headline" id="Refresh_ROOT_version.3F">Refresh
                  ROOT version?</span></h3>
              <p>We looked at the <a rel="nofollow" class="external
                  text" href="https://root.cern.ch/releases">list of
                  releases of ROOT</a> and noted that the version that
                we are using at present, 6.08.06, is already marked as
                "Old" on the site. Normally we would consider upgrading.
              </p>
              <ul>
                <li> David reported that the latest version changes the
                  interface into the TMVA routines.</li>
                <li> Alex pointed out that it is right at the beginning
                  of a run, not a great time to change the software.</li>
                <li> Others pointed out the next time we will not be
                  running is several months from now (hopefully).</li>
                <li> No one present had an example of a new feature that
                  we would benefit from.</li>
              </ul>
              <p>We decided for now to do nothing. If collaborators have
                opinions about an upgrade, particularly if there are new
                features they want to take advantage of, please write to
                the offline list or contact Mark.
              </p>
              <h3><span class="mw-headline"
                  id="New_track_matching_on_the_master_branch">New track
                  matching on the master branch</span></h3>
              <p>We went through <a rel="nofollow" class="external
                  text"
href="https://mailman.jlab.org/pipermail/halld-offline/2017-December/003043.html">Mark's
                  email</a> from before the holidays describing reduced
                efficiency for FCAL photons associated with a large
                change in the track matching code from Simon.
              </p>
              <ul>
                <li> Simon reported that he thinks the anomalies are due
                  to a lack of tuning of matching parameters with the
                  new algorithm. He will look into this.</li>
                <li> Alex noted that a significant change like this
                  makes comparison with previous reconstruction results
                  difficult when trying to monitor incoming data.</li>
                <li> Alex also pointed out some strangeness in the TOF
                  occupancy for track-matched hits.</li>
                <li> We discussed options for maintaining availability
                  of the old algorithm:
                  <ol>
                    <li> The latest tag was applied before the change,
                      so that can be used. Alex remarked that there are
                      changes made after that tag that one might want to
                      have.</li>
                    <li> We discussed how hard it would be to reverse
                      the changes on the master branch. There is some
                      fear that it might not be easy.</li>
                    <li> Another options is to create a parallel branch
                      that has all changes except those brought in for
                      the new algorithm. This faced difficulties similar
                      to the previous option.</li>
                  </ol>
                </li>
              </ul>
              <p>We decided to keep the changed on the master branch for
                now while Simon pursues his parameter setting studies.
                In the meantime Mark will look at the feasibility of
                implementing option (3).
              </p>
              <p>We discussed how to merge in changes to the master when
                the number of changed lines of code is large and the
                effects potentially significant. The majority of pull
                requests are clearly not of this nature. We coalesced on
                a policy where, if there is concern about a large
                change, the proposed branch should be tested by someone
                other than the author, beyond the light testing we get
                with the pull-request auto-build. For example, the
                offline monitoring suite can be run against the branch.
                Collaborators should not blithely merge in a pull
                request that is large without some discussion in the
                pull-request conversation on GitHub. Here "large" is
                somewhat vague; we are hoping we will collectively
                recognize a large change when we see one.
              </p>
              <h3><span class="mw-headline"
                  id="Docker_Containers_.2B_GlueX">Docker Containers +
                  GlueX</span></h3>
              <p>David has been working on getting reconstructions jobs
                running at NERSC in the context of his LDRD grant for
                JANA2. Doing that involves using containers; a tool
                which is gaining widespread use in recent years. He
                described his recent experience and plans for further
                work. Please see <a rel="nofollow" class="external
                  text"
href="https://docs.google.com/presentation/d/18GqzCdT87PhgyMsxpN7I1QGtijhYKc35tQ_JEjNH7rg/edit?usp=sharing">his
                  slides</a> for all of the details.
              </p>
              <h3><span class="mw-headline" id="Hall_D_Disk_Usage">Hall
                  D Disk Usage</span></h3>
              <p>Alex brought our attention to the level of use of work,
                cache, and volatile to support recent reconstruction and
                analysis launches. We are near the upper limits on all
                of them. See the <a rel="nofollow" class="external
                  text"
                  href="https://scicomp.jlab.org/scicomp/#/?username=">SciComp
                  webpages</a> for the status. Work especially has been
                a problem. With the move to the new fileserver, we run
                into hard limits when we exceed our allotment and that
                allotment is much smaller than we were using before the
                move. The following table was shown, reflecting work
                disk use as of December 31.
              </p>
              Sum of all files owned by user
              <table border="border">
                <tbody>
                  <tr>
                    <th>Rank</th>
                    <th>Total Size (GB)</th>
                    <th>User</th>
                  </tr>
                  <tr>
                    <td>1</td>
                    <td>5305.20</td>
                    <td>acernst
                    </td>
                  </tr>
                  <tr>
                    <td>2</td>
                    <td>4032.21</td>
                    <td>gxproj5
                    </td>
                  </tr>
                  <tr>
                    <td>3</td>
                    <td>3716.53</td>
                    <td>jrsteven
                    </td>
                  </tr>
                  <tr>
                    <td>4</td>
                    <td>3380.35</td>
                    <td>somov
                    </td>
                  </tr>
                  <tr>
                    <td>5</td>
                    <td>3038.87</td>
                    <td>gluex
                    </td>
                  </tr>
                  <tr>
                    <td>6</td>
                    <td>2715.98</td>
                    <td>staylor
                    </td>
                  </tr>
                  <tr>
                    <td>7</td>
                    <td>2678.60</td>
                    <td>stepi
                    </td>
                  </tr>
                  <tr>
                    <td>8</td>
                    <td>2117.81</td>
                    <td>aaustreg
                    </td>
                  </tr>
                  <tr>
                    <td>9</td>
                    <td>1815.50</td>
                    <td>ilarin
                    </td>
                  </tr>
                  <tr>
                    <td>10</td>
                    <td>1703.46</td>
                    <td>gxproj1
                    </td>
                  </tr>
                </tbody>
              </table>
              <p>David suggested sending out this table to the offline
                email list on a regular basis. In any case collaborators
                are encouraged to evaluate the amount of data that they
                need spinning. The rest should be archived to tape.
              </p>
            </div>
            <br>
          </div>
        </div>
      </div>
    </div>
    <pre class="moz-signature" cols="72">-- 
Mark Ito, <a class="moz-txt-link-abbreviated" href="mailto:marki@jlab.org">marki@jlab.org</a>, (757)269-5295
</pre>
  </body>
</html>