GlueX Data Challenge Meeting, August 27, 2012

From GlueXWiki
Jump to: navigation, search

Meeting Time and Place

The meeting will be on Monday August 27, 2012 at 1:30pm EDT. For those people at Jefferson Lab, the meeting will be in room F326.

Meeting Connections

To connect from the outside:

1.) ESNET:

   Call ESNET Number 8542553 (this is the preferred connection method).

2.) Phone: (should not be needed)

  +1-866-740-1260 : US and Canada
  +1-303-248-0285 : International
    then use participant code: 3421244# (the # is needed when using the phone)
   then type access code 3421244 into "join a meeting" (you need java plugin)

3.) EVO:

   A conference has been booked under "GlueX" from 1:00pm until 3:30pm (EST).




  • CMU: Curtis Meyer
  • EVO: Matt Shepherd
  • FSU: Nathan Sparks
  • JLab: Mark Ito (chair), Elton Smith, Simon Taylor
  • UConn: Richard, [student?]

JLab Farm Mini Data Challenge

Mark gave a snapshot of the current mini challenge. See his wiki page for details.

  • The current set of jobs has been able to saturate the Hall D share of the farm, which is only about 4% at this point.
  • Richard will look into how much of the 35 kB per event is real raw data and how much is truth information.
  • Most of the analysis jobs (HD_ROOT) crashed due to the self-declared memory limit of 2 GB. Paul Mattione has checked in an option to cut-off reconstruction of high multiplicity events. This may help.
  • One of the next steps is to produce output data in REST format.
  • Richard asked about proceeding with a grid-based data challenge. We decided some time ago that we would pursue this, and re-endorsed that decision. Richard will propose a plan at the next meeting.
  • We discussed the idea of moving reconstructed data from the grid for storage on tape at JLab. Mark will look into current availability of tape resources. This would exercise the SRM facility that we plan to use.


Mark described a system, CernVM, used by the LHC experiments, for mass distribution of experimental software in a platform-independent form. It involves a standard virtual machine and an exported file system so that end users (or grid nodes) need not build the software themselves. This was suggested as an option by one of the reviewers at the June Software Review.

Mark and Richard both thought that this was probably overkill for us, despite that fact that it solves many of the problems that we encounter regularly. The overhead may not be worth it. The current plan is to continue to rely on locally installed versions in a central location, available publicly within each institution.