GlueX Offline Meeting, July 11, 2012

From GlueXWiki
Jump to: navigation, search

GlueX Offline Software Meeting
Wednesday, July 11, 2012
1:30 pm EDT
JLab: CEBAF Center, F326/327

Agenda

  1. Announcements
  2. Review of minutes from the last meeting: all
  3. Planning for the next Data Challenge: Curtis
    1. GlueX-doc-2031.
    2. Notes on the Data Challenge: Mark
  4. REST format: Richard
  5. Reconstruction sub-group reports
    1. Calorimeters
    2. Tracking
    3. PID
  6. Action Item Review
  7. Review of recent repository activity: all

Communication Information

Video Conferencing

Slides

Talks can be deposited in the directory /group/halld/www/halldweb/html/talks/2012-3Q on the JLab CUE. This directory is accessible from the web at https://halldweb.jlab.org/talks/2012-3Q/ .

Minutes

Present:

  • CMU: Will Levine, Paul Mattione, Curtis Meyer
  • IU: Ryan Mitchell, Matt Shepherd
  • JLab: Eugene Chudakov, Mark Ito (chair), David Lawrence, Simon Taylor, Elliott Wolin
  • UConn: Richard Jones

Planning for the next Data Challenge

Curtis introduced the topic and lead us through his GlueX Note. The contents

  1. Introduction
  2. Earlier Data Challenges
  3. Goals of The Next Data Challenge
  4. Procedures
    1. Generate pythia Events
    2. Inject Physics into the Sample
    3. Producing DSTs from the Monte Carlo
    4. Physics Analysis of DSTs
    5. Amplitude Analysis of mini-DSTs
  5. Conclusions

See his notes for details.

Mark then led us through a set of notes outlining a possible direction.

  • Ideas: He summarized communication from interested folks since the last offline meeting.
  • Tools: He listed some tools that may help us.
  • Mini Data Challenges: He proposed a series of short data challenges to help develop tools and refine goals.
  • Analysis System: He endorsed Matt's idea that we include a reconstructed data delivery system as part of this effort.

See his wiki page for details.

Discussion:

  • David suggested that we get more than one person involved in the effort.
  • Richard advocated the use of glideinWMS as a work management system rather than PanDA.
  • David wondered whether the extra layer of a work management system gave us any real benefit. Richard pointed out that some of the functionality that Mark mentioned (tracking output files, etc.) may not be provided by these systems.
  • Curtis announced that he has asked Mark and Matt to manage the effort. Bi-weekly meetings will be called.

REST Format

Richard ran generated some data on the grid with the current analysis framework to measure the size of the REST output events. He simulated events with 5 pions and a proton in the final state.

Section Size (bytes) Comment
Monte Carlo 500 particle list with kinematics, vertices
Tagger 170 20 hits on average
Clusters 600 9 on average, notation about track matching
DChargedTrackHypothesis 1484 9 on average

Total event size is on average about 2.7 kB, 1.8 kB after compresssion. Other comments:

  • Off-diagonal elements of the covariance matrices for the clusters are often zero.
  • No kaons are produced at present.
  • Antiprotons are seen in the data.

Richard then followed a suggestion by Paul and Matt to store more information from lower levels in the reconstruction.

  • Rather than recording timing chi-squareds, record actual times of TOF hits: adds 70 bytes
  • Similar increase for start counter hits.

These will be included in the future.

There was a discussion about whether the lower-level DTrackTimeBased should be used rather that DChargedTrackHypothesis. The problem is that this object has way more member data than we want to serialize. Matt suggested writing out just the relevant member data and protecting access of missing data by generating errors in their gettor functions when the data is not present. We agreed to follow this approach.

Richard also looked into using ROOT trees as a DST format. He found a fundamental conflict between the way events are accessed from a ROOT tree and the JANA multi-threaded architecture when the ROOT tree is used as an input file. Creating ROOT trees for subsequent analysis by ROOT is not an issue, of course.

New Action Items

  1. Look into track hypotheses that are produced by default. -> Simon
  2. Reconfigure REST to use DTrackTimeBased. -> Richard