GlueX Offline Meeting, October 14, 2015

From GlueXWiki
Jump to: navigation, search

GlueX Offline Software Meeting
Wednesday, October 14, 2015
1:30 pm EDT
JLab: CEBAF Center F326/327


  1. Announcements
  2. Review of minutes from September 30 (all)
  3. Offline Monitoring (Kei)
  4. Data Challenge 3 update (Mark)
  5. Future Commissioning Simulations (all)
  6. Auto-Build on Pull Request (Sean)
  7. The Meaning of the Run Number (Mark)
  8. Binary distributions of GlueX Software? (Nathan)
  9. b1pi results review
  10. Review of recent pull requests
    • comments on merge
    • alternate workflows for submitting pull requests
    • rebasing?
  11. Action Item Review

Communication Information

Remote Connection


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



  • FSU: Brad Cannon
  • FIU: Mahmoud Kamel
  • JLab: Alex Barnes, Amber Boehnlein, Mark Ito (chair), Paul Mattione, Nathan Sparks, Beni Zihlmann
  • NU: Sean Dobbs
  • UConn: James McIntyre

There is a recording of this meeting on the BlueJeans site.

Announcement: b1pi test

Mark increased the number of events in the semi-weekly b1pi test from 50 k to 150 k. The script was modified to run on the five platforms in parallel, facilitating this change. Also, Paul relaxed the probability cut on the kinematic fits a week or so ago, boosting the statistics in the related plots by a lot.

Review of minutes from September 30

We looked over the minutes.

  • The schedule for work disk conversion to the new Lustre server has not been set yet.
  • Mark has started submitting jobs to finish off the last 20% of the Spring 2015 simulations.

Data Challenge 3

Mark has started submitting jobs for Data Challenge 3 under a new SWIF-based system. This is the initial test of the system at this point.

Future Commissioning Simulations

Sean gave a brief update on status. A set of files for defining the jobs exists. We can start pilot jobs now. Mark agreed to take a look.

Brad asked about the recent fix to mcsmear so that it uses the correct run number to look up calibration constants. The current version of the code being for the Spring does not have this change. Sean browsed the code and the constants and did not find any cases where this would make a difference in results. On the other hand Brad reported significant improvements after going to the new code; he will look further to make sure that this particular effect is responsible for the changes he saw.

Sean pointed out that in any case, we should tag a new release before getting started with new simulated data sets.

Auto-Build on Pull Request

Sean reported that the system is up and running now. He had some back-and-forth with Marty Wise of CNI on setting up the authentication system and those issues were worked out. Mark submitted a pull request earlier in the week that got auto-built successfully. The system writes a comment on the pull request at the the GitHub site. Those subscribed to sim-recon notifications will see the comment. It indicates success or failure and gives links to the error summary and build log file. The build is done on the ifarm and uses our work disk at present.

The Meaning of the Run Number

Mark went over a wiki page summarizing the discussion we had two meetings ago on the source and use of the run number in simulations. Richard had introduced the topic in the context of HDGeant4. Not only are there several possible sources for the run number (input events from generators, FFREAD cards) but there also could be a distinction between which run number is used to obtain calibration constants and which run number is output in the simulated events. Richard had made a proposal which seemed reasonable to the group.

Binary distributions of GlueX Software?

Nathan is working on a system of packaging up the results of builds done with the HDPM system and creating a binary distribution of GlueX software. We is packaging sim-recon separately from the rest of the required software packages. There was agreement that such product would be useful, especially for collaborators outside the Lab starting out with the software. He will let us know how it is going at a future meeting.