GlueX Offline Meeting, August 31, 2016

From GlueXWiki
Jump to: navigation, search

GlueX Offline Software Meeting
Wednesday, August 31, 2016
1:30 pm EDT
JLab: CEBAF Center F326/327


  1. Announcements
    1. sim-recon release: version 2.4.0 (Mark)
    2. build_scripts release: version 1.2 (Mark)
  2. Review of minutes from the last meeting (all)
  3. Report from SciComp August 25th Meeting (Mark)
  4. Launches (Paul/Alex A./Sean)
  5. Offline EVIO skim improvements (Sean)
  6. Change meeting time to 2:00 pm?
  7. Review of recent pull requests (all)
  8. Review of recent discussion on the Gluex Software Help List.
  9. Action Item Review

Communication Information

Remote Connection


Talks can be deposited in the directory /group/halld/www/halldweb/html/talks/2016 on the JLab CUE. This directory is accessible from the web at .



  • CMU: Naomi Jarvis, Curtis Meyer
  • IU: Matt Shepherd
  • JLab: Alexander Austregesilo, Brad Cannon, Mark Ito (chair), Paul Mattione, Nathan Sparks, Simon Taylor, Beni Zihlmann
  • NU: Sean Dobbs
  • UConn: Richard Jones


  1. sim-recon release: version 2.4.0. Mark reminded us that this came out August 24. It is exactly the same as offmon-2016_02-ver06.
  2. build_scripts release: version 1.2. Mark notes in his email that the idea is make it easier for folks working at JLab to set-up an environment that is the same as some "standard" version, except that a custom, user-defined build of sim-recon is used.

Review of minutes from the last meeting

We went over the minutes from the meeting on August 17.

  • Again, no new work on bending the curve on plugin growth in sim-recon. This does seem to be a real issue; it affects build times and disk footprint. Nathan noted that for people who are building private version of sim-recon and are trying to save on disk space, one can switch off inclusion of debugging symbols on the SCons command line:
scons DEBUG=0
  • sim 1.1 is completely done. Those last 20 jobs completed successfully.
  • Mark spoke with David about taking advantage the new HDDM multi-threaded I/O under JANA. It would indeed take some non-negligible work. We don't have a volunteer to do this at present, but the demand does not seem high at this point either.

Report from the August 25th SciComp Meeting

Mark gave the report. Of the items on the agenda, most of the time was taken with the first item. Chip Watson has circulated a white paper describing a proposal for peer-review-based planning and allocation of computing resources on the JLab farm. Mark encouraged us to look over the proposal as a basis for future discussion and feedback. Major changes to the way we do planning for farm use and how that use is managed could start appearing soon.

[Added in press] Graham Heyes has also circulated an email initiating discussion within Experimental Nuclear Physics at JLab.


Last Monitoring Launch

Alex reviewed his announcement of completion of the monitoring launch. This launch tested two new capabilities: use of ROOT 6 and the new EVIO parser from David Lawrence.

Independently, Alex did a comparison of the launch code compiled against ROOT 5 versus the same code compiled with ROOT 6. The resulting histograms were identical.

This brought us to a discussion of where we stand on the transition from ROOT 5 to 6. Nathan brought up two issues:

  1. When analyzing trees from the analysis launch, ROOT 5 goes about 50% faster.
  2. There is an incompatibility between ROOT 6 and the DevTool technique for upgrading the compiler on a "RedHat" 6 machine. See his email for details. This can be finessed by building ROOT 6 with the deprecated ./configure-make method.

We decided to make ROOT 6 the default for builds going forward. ROOT 5 compatibility will continue to be a goal for the standard build, and instances of such builds will be maintained at JLab. Paul mentioned that he will try to keep ROOT 5 compatibility for the analysis library[?].

Analysis Launch on sim1.1

Alex completed this last week, as he had promised. See his announcement for the details.

Next Reconstruction Launch

Paul gave the report:

  • The original deadline for code changes was today. It has been moved forward to Friday.
  • Will include Will McGinley's new BCAL non-linearity correction and the inclusion of pre-shower energies into REST.
  • Will include Mark Dalton's covariance matrix for BCAL showers if ready. They will have to be tested for their effect on kinematic fitting.
  • Will try to include tracking changes from Simon. He is looking at inefficiencies in certain regions of the tracking space for busy events (4πp). He is working on changes to the track finding code. The changes have not been pushed to GitHub yet and are still under test.
  • Paul is looking at the cause for asymmetries Reinhard Schumacher has reported in Reinhard's anti-proton analysis when he applies a tight cut on kinematic fit confidence level. Paul thinks he may have a fix, but has not really tried it yet. If this fix is not the root cause, we may have to go ahead with the launch anyway.

Offline EVIO skim improvements

Sean has been working on tools to reduce the size of EVIO skims (raw data), and has applied them to the pi0 skims for the FCAL and BCAL. The user can specify reconstructed objects of interest, and only the raw data needed to perform the reconstruction of those objects will be saved in the output events. For these pi0 skims, the fully-reconstructed DVertex object is also saved so that the event origin is known without having to re-do tracking. This results in a reduction of the skim file sizes by a factor of 40 to 50. This work was facilitated by use of the new EVIO event parser.

[Added in press, from Sean] Will M. just told me [Sean] that with this reduced BCAL EVIO pi0 skim, he is seeing a processing rate of 84.5 kHz compared to 5.6 Hz with the old pi0 skim, using 4 threads. So, not having to do tracking gives us 4 orders of magnitude improvement.

Change meeting time to 2:00 pm

We decided to move the time of the meeting from 1:30 pm to 2:00 pm, following the example of the Online Meeting.

Stale Branches

Mark reminded us that we should delete branches from the Git repository that we do not need anymore. The person who created the branch originally is responsible for deleting it when it has served its purpose. See the GitHub site for a list of stale branches.