<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Folks,<br>
    <br>
    Please find the minutes below and at <a class="moz-txt-link-freetext" href="http://tinyurl.com/qeteeyf">http://tinyurl.com/qeteeyf</a> .<br>
    <br>
      -- Mark<br>
      ________________________<br>
    <div id="globalWrapper">
      <div id="column-content">
        <div id="content" class="mw-body" role="main">
          <h3 id="firstHeading" class="firstHeading" lang="en"><span
              dir="auto">GlueX Offline Meeting, August 5, 2015, </span><span
              class="mw-headline" id="Minutes">Minutes</span></h3>
          <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</li>
                <li> <b>FSU</b>: Aristeidis Tsaris</li>
                <li> <b>JLab</b>: Alex Barnes, Mark Dalton, Mark Ito
                  (chair), David Lawrence, Paul Mattione, Kei Moriya,
                  Eric Pooser, Nathan Sparks, Justin Stevens, Simon
                  Taylor, Beni Zihlmann</li>
                <li> <b>NU</b>: Sean Dobbs</li>
              </ul>
              <h3><span class="mw-headline" id="Announcements">Announcements</span></h3>
              <ol>
                <li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/jlab-scicomp-briefs/2015q3/000102.html"><b>The
                      meaning of ifarm has changed</b></a>. Use
                  "ifarm62" for CentOS 6.2, "ifarm65" for CentOS 6.5.
                  "ifarm" is the same as "ifarm65" (it used to point to
                  CentOS 6.2 nodes).</li>
                <li> <b><a
href="https://halldweb.jlab.org/wiki/index.php/Policy_on_CCDB_Variations_for_Reconstructing_Simulated_Data"
                      title="Policy on CCDB Variations for
                      Reconstructing Simulated Data">Policy on CCDB
                      Variations for Reconstructing Simulated Data</a></b>.
                  This new wiki page summarizes our policy on how to use
                  CCDB variations with Monte Carlo data.</li>
                <li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2015-July/002108.html"><b>New
                      releases hdds 3.3, sim-recon 1.4.0</b></a>. Note
                  that the release notes are now being posted on GitHub.
                </li>
                <li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2015-August/002111.html"><b>ccdb_changes
                      email list</b></a>. The new list sends out a daily
                  digest of changes to the CCDB.</li>
                <li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2015-August/002112.html"><b>New
                      Git Guide</b></a> Paul transcribed his notes from
                  his personal climb of the Git learning curve.</li>
                <li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2015-August/002113.html"><b>Github
                      for Mac</b></a>. David pointed us to a
                  GitHub-distributed application for the Mac desktop. </li>
                <li> <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_FAQ#I_am_getting_a_.22403_Forbidden.22_error_when_trying_to_push_to_a_GitHub_repository_from_JLab._What_is_wrong.3F"
                    title="GlueX Offline FAQ"><b>Git versions on the
                      JLab CUE</b></a>. Simon and Elton found some
                  problems with specific versions of Git installed at
                  JLab. Suggested combination: /apps/bin/git on ifarm65
                  or jlabl*.</li>
                <li> <a rel="nofollow" class="external text"
href="https://mailman.jlab.org/pipermail/halld-offline/2015-August/002115.html"><b>Emulation
                      mode changes</b></a>. David reviewed his recent
                  email describing his proposed changes to control of
                  Flash-ADC emulation, aka, creating summary data from
                  raw waveforms in the offline environment.</li>
              </ol>
              <h3><span class="mw-headline"
                  id="Review_of_minutes_from_July_22">Review of minutes
                  from July 22</span></h3>
              <p>We went over <a
href="https://halldweb.jlab.org/wiki/index.php/GlueX_Offline_Meeting,_July_22,_2015#Minutes"
                  title="GlueX Offline Meeting, July 22, 2015">the
                  minutes</a>. There was discussion on a few items:
              </p>
              <ul>
                <li> We still need to work out details of doing an
                  HDDM/EVIO merge so that we can mix in real background
                  events with simulated physics events.</li>
                <li> David mentioned that there are some changes needed
                  in JANA to support use of ROOT 6.</li>
                <li> Mark found out that the lack of notification to
                  repository watchers when a direct push to GitHub
                  repositories is a feature, not a bug. See <a
                    rel="nofollow" class="external text"
href="https://help.github.com/articles/receiving-email-notifications-for-pushes-to-a-repository/">this
                    page</a> on GitHub for details. Turns out only two
                  email addresses can be added to the distribution list;
                  one of them should be a group email address. We
                  decided not to turn on the feature to avoid excessive
                  traffic on <a class="moz-txt-link-abbreviated" href="mailto:halld-offline@jlab.org">halld-offline@jlab.org</a>.</li>
              </ul>
              <h3><span class="mw-headline" id="Offline_Monitoring">Offline
                  Monitoring</span></h3>
              <p>Kei gave a detailed <a rel="nofollow" class="external
                  text"
href="https://halldweb.jlab.org/wiki/images/8/83/2015-07-29-offline_monitoring.pdf">report</a>
                at the <a rel="nofollow" class="external text"
href="https://halldweb.jlab.org/wiki/index.php/July_29,_2015_Calibration">previous
                  calibration meeting</a>. He continues to work with
                Chris Larrieu on SWIF features and is relying more and
                more on it for the launches.
              </p>
              <h3><span class="mw-headline"
                  id="Spring_2015_Commissioning_Simulations">Spring 2015
                  Commissioning Simulations</span></h3>
              <p>Sean reports that the creation of the HDDM raw data for
                the <a
href="https://halldweb.jlab.org/wiki/index.php/Spring_2015_Commissioning_Simulations"
                  title="Spring 2015 Commissioning Simulations">Spring
                  2015 Commissioning Simulations</a> is practically
                complete. The data is available in the
                /volatile/halld/detcom_02/smeared directory. It still
                remains to do the reconstruction pass on the data.
              </p>
              <h3><span class="mw-headline" id="Geant4_Update">Geant4
                  Update</span></h3>
              <ul>
                <li> Richard has completed the incorporation of the
                  three types of event sources:</li>
              </ul>
              <p>particle gun, coherent bremsstrahlung (now implemented
                as a C++ class), and HDDM. Note that genr8 and bggen
                both create HDDM-formatted events.
              </p>
              <ul>
                <li> Secondary vertices can be stored and examined
                  later.</li>
                <li> The complete PDG particle list has been
                  implemented.</li>
                <li> Richard is suggesting using curated physics lists
                  from the LHC experiments rather than struggling to
                  assemble our own. He is following David's example and
                  is using a hybrid of LHCb and FRITIOF.</li>
                <li> Next is to do a detailed comparison of particle
                  propagation between GEANT 3 and Geant4.</li>
                <li> He is using the boost library for Python hooks and
                  some special functions. This means that we will have
                  to install this package on our machines to get a
                  successful build.</li>
                <li> The next major task to work on creating the
                  detector hits from the sensitive detectors.</li>
                <li> The code can be cloned from GitHub and built. The
                  URL is <a rel="nofollow" class="external free"
                    href="https://github.com/rjones30/HDGeant4.git">https://github.com/rjones30/HDGeant4.git</a>.</li>
              </ul>
              <h3><span class="mw-headline"
                  id="Overhaul_of_the_ROOT_TTree_Format">Overhaul of the
                  ROOT TTree Format</span></h3>
              <p>Paul led us through <a rel="nofollow" class="external
                  text"
href="https://mailman.jlab.org/pipermail/halld-offline/2015-July/002103.html">his
                  email</a> outlining the need for changes to the tree
                format. He said,
              </p>
              <blockquote>It needs to be done, I'm going to it,..., if
                you have any comments by Friday let me know.</blockquote>
              <p>Mark asked if the primary motivation was to take
                advantage of multi-threaded processing with PROOF. Paul
                explained the situation is more complicated than that
                one issue. User code might be simpler in certain
                circumstances in the new scheme and multi-threaded
                processing would be an option not available now.
              </p>
              <h3><span class="mw-headline"
                  id="Conversion_from_Subversion_to_Git:_discussion">Conversion
                  from Subversion to Git: discussion</span></h3>
              <p>We had an unstructured discussion about our experience
                so far with Git.
              </p>
              <ul>
                <li> People seem to generally like it.</li>
                <li> David is still finding some details and concepts
                  that need to be understood to use Git effectively.</li>
                <li> Simon will try the "git diff --cached" command to
                  look at difference between staged files and
                  repository.</li>
                <li> David noted that there is a bit of blame sharing
                  with pull requests being issued by one person and
                  merged in by another, a new twist.</li>
                <li> David is liking the local nature of Git and the
                  ease in making sandboxes to play with changes. He also
                  noted the ease in changing from branch to branch. I
                  that context, he test drove the "git stash" command
                  and it performed as expected.</li>
                <li> Mark solicited comments on whether the workflow we
                  are using is too protective against changes or too
                  accommodating of them. There was no real comment,
                  which he interpreted as "about right".</li>
                <li> Justin mentioned that at the S&T review, he was
                  asked how we protect against badly broken code getting
                  checked into the repository. He told the committee
                  that we have changed to Git and that gives us a
                  measure of control.</li>
                <li> David noted that the email volume from watching the
                  repositories seems higher than with Subversion.</li>
                <li> David thought that although we are merging pull
                  requests without a lot of review right now, going
                  forward, as more junior members of the collaboration
                  make pull requests, those requests in particular might
                  get more careful scrutiny, as is appropriate.</li>
                <li> Sean proposed that we have builds triggered on pull
                  requests. He mentioned that there are tools out there
                  to do things like that.</li>
              </ul>
              <h3><span class="mw-headline"
                  id="Proposed_move_to_Git:_build_scripts.2C_gluex_install.2C_jproj">Proposed
                  move to Git: build_scripts, gluex_install, jproj</span></h3>
              <p>Mark I. proposed moving version control of some of the
                packages he has been maintaining from Subversion to Git.
                There were no objections, but the topic generated
                discussion on other related topics.
              </p>
              <ul>
                <li> Mark I. is proposing to create three new
                  repositories on GitHub. Justin thought we might want
                  to have a "scripts" repository and have these projects
                  in subdirectories of that repository, like they are
                  currently in Subversion. Mark thought that the
                  repositories should be more like single-purpose
                  projects one repository per project. David noted that
                  this scheme will lead to a lot of repositories.</li>
                <li> Justin observed that since all of the repositories
                  are under the Jefferson Lab organization at GitHub on
                  a single level, it is very difficult to browse the
                  list and figure out which ones one needs. The name
                  "build_scripts" gives you no clue that the repository
                  is relevant for GlueX work.
                  <ul>
                    <li> Curtis thought we might want to prepend "HD" or
                      something similar to the names of all of our
                      repositories.</li>
                    <li> Mark I. noted that if one goes to the "GlueX
                      Team" page at GitHub, one can click on a link to
                      get a list of all repositories that the team is
                      allowed to write to.</li>
                    <li> Mark thought that the situation is like the
                      DocDB in that you cannot simply browse the titles
                      to find the document you need. Rather you need a
                      reference into the title space to get the document
                      you want.</li>
                  </ul>
                </li>
                <li> David pointed out that to get everything needed to
                  build a working system, there are several packages
                  that one needs to get and that the list cannot be
                  intuited or guessed at. One needs an HDPM or a
                  gluex_install.
                  <ul>
                    <li> David further noted that gluex_install does not
                      work on Mac. We discussed ways that Mark I. could
                      do some testing on a Mac platform.</li>
                    <li> Paul noted that there is a concept called
                      "submodules" in Git that might help.</li>
                  </ul>
                </li>
              </ul>
              <p>We did not come to conclusions on these issues, but
                clearly we will have to return to them.
              </p>
              <h3><span class="mw-headline" id="Action_Items">Action
                  Items</span></h3>
              <ol>
                <li> Work out details of doing an HDDM/EVIO merge.
                  (Sean, David)</li>
                <li> Complete work on changes to be compatible with ROOT
                  6. (Beni, David)</li>
                <li> Overhaul of the ROOT TTree Format. (Paul)</li>
                <li> Come up with a policy on organizing Git
                  repositories and repository names. (Mark and
                  interested parties)</li>
              </ol>
            </div>
            <div class="printfooter">
              Retrieved from "<a dir="ltr"
href="https://halldweb.jlab.org/wiki/index.php?title=GlueX_Offline_Meeting,_August_5,_2015&oldid=69214">https://halldweb.jlab.org/wiki/index.php?title=GlueX_Offline_Meeting,_August_5,_2015&oldid=69214</a>"</div>
          </div>
        </div>
      </div>
      <div id="footer" role="contentinfo">
        <ul id="f-list">
          <li id="lastmod"> This page was last modified on 6 August
            2015, at 17:16.</li>
        </ul>
      </div>
    </div>
    <br>
  </body>
</html>