GlueX Offline Meeting, January 20, 2016

From GlueXWiki
Jump to: navigation, search

GlueX Offline Software Meeting
Wednesday, January 20, 2016
1:30 pm EST
JLab: CEBAF Center F326/327


  1. Announcements
    1. DL1Trigger added (David)
    2. Upgrade to Xerces-C++ done (Mark)
    3. Compiler Survey Responses In: mostly GCC 4.4 (Mark)
    4. Sim-recon 1.9.0 tagged on GitHub (not built at JLab yet) (Mark)
    5. Paper-based Software Review (David, Mark)
    6. Corrupted files on Lustre
  2. Review of minutes from January 6 (all)
  3. Collaboration Meeting
  4. Offline Monitoring (Paul)
  5. RCDB vs. CCDB for Offline Reconstruction/Analysis (Mark et al.)
  6. Geant4 Update (Richard, David)
  7. Review of recent pull requests (all)
  8. Data Challenge 3 update (Mark)
  9. Future Commissioning Simulations (all)
  10. 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, Mike Staib
  • FIU: Mahmoud Kamel
  • JLab: Mark Ito (chair), David Lawrence, Paul Mattione, Dmitry Romanov, Nathan Sparks, Sascha Somov, Justin Stevens, Simon Taylor, Beni Zihlmann
  • NU: Sean Dobbs
  • UConn: James McIntyre


  1. DL1Trigger added. David led us through his email. Trigger bits from both the GTP and the front panel of the TS are now produced from a JANA factory. Sascha will put together a list of quasi-permanent trigger bit assignments.
  2. Upgrade to Xerces-C++ done. Mark flashed his email from last Thursday. Builds of JANA, HDDS, and sim-recon against both 3.1.1 and 3.1.2 are available, but the default is 3.1.2.
    • Nathan asked about using Xerces-C++ from the various Linux distributions rather than building our own. Beni reported difficulty doing this under Ubuntu. CentOS6 is at 3.0.1, relatively old. We do have the build-our-own thing under control as well. We concluded there is no pressure to switch, but it is something to keep in mind.
  3. Compiler Survey Responses In. Mark told us that most sites report that they are using GCC 4.4. As a result we should probably delay allowing developers to use language features only supported by more recent versions.
  4. Sim-recon 1.9.0 tagged on GitHub. Mark made the announcement. Notably it includes the new "curving shower" BCAL code from Tegan.
  5. Paper-based Software Review. Mark and David reported that Chip Watson and Graham Heyes are thinking about having a software review where only written reports will be circulated, no visiting committee. They have asked for documentation about how we are doing with respect to previous review recommendations and significant updates on software progress. They would also like us to update our computing resource requirement estimates.
  6. Corrupted files on Lustre. From the Computer Center website:

Due to a hardware failure over the weekend, a small subset of files on the scientific computing Lustre system were lost. This affects files in /work, /cache, and /volatile. If your data is affected, file access attempts will return the error "Cannot send after transport endpoint shutdown". The scientific computing group is working on automatically removing the affected files. Users who see this message in the meantime should remove the files with the "unlink" command, after which each file can be manually recreated. The Scientific Computing group is working with the vendor on a long term stability fix for the affected file servers.

Review of minutes from January 6

Mark sent out the proposal for intentional gaps in the sequence of run numbers to the Collaboration. There was not a lot of discussion generated. The group putting together sim1 have decided to go ahead on the assumption that a run 10,000 start is a good guess for the Spring.

Collaboration Meeting

Mark canvased the group for those wishing to give a talk. He expects to hear from those interested.

RCDB vs. CCDB for Offline Reconstruction/Analysis

Mark introduced the issue of whether the offline analysis should get constants directly from the RCDB or whether we should copy the constants to the CCDB and access them from there. There are good arguments on both sides. See his slides for details.

After much discussion, we settled on a two-prong approach:

  1. Dmitry will write a C++ API for the RCDB. This is likely essential for some online applications, but will not become part of sim-recon right away.
  2. We will also write some scripts to copy data from the RCDB to the CCDB and see if any fundamental difficulties reveal themselves.