Revision as of 11:29, 8 March 2012

GlueX Offline Software Meeting (non-standard room)
Wednesday, March 7, 2012
1:30 pm EST
JLab: ARC 428

Agenda

1. Announcements
2. Review of minutes from the last meeting: all
3. Reconstruction sub-group reports
   1. Calorimeters
      1. FCAL Reconstruction in b1pi events 03/06/2012: Will
   2. Tracking
      1. fix to the "bogus track candidate" problem: Simon
   3. PID
      1. PID library changes: Paul
4. Offline Software Review Planning
5. Calibration Discussions in this Working Group
6. Time for a new release?
7. Action Item Review
   • Recently Resolved
   • Outstanding Items
8. Review of recent repository activity: all

Communication Information

Video Conferencing

• ESNet: 8542553
• EVO:
  • Meeting URL: http://evo.caltech.edu/evoNext/koala.jnlp?meeting=ete8eavBvvanaaIiaiIt
  • Phone Bridge ID: 11 6471

Telephone

To connect by telephone:

1. dial:
   • US and Canada: (866)740-1260 (toll free)
   • International: (303)248-0285 (toll call) or look up toll-free number at http://www.readytalk.com/intl
2. enter access code followed by the # sign: 3421244#

Chairman's cell-phone: (757)768-2364

Slides

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

Minutes

Present:

• CMU: Will Levine, Paul Mattione, Curtis Meyer
• IU: Kei Moriya, Matt Shepherd
• JLab: Graham Heyes, Mark Ito (chair), David Lawrence, Simon Taylor, Elliott Wolin, Beni Zihlmann

CLHEP

Mark proposed that we include [???|CLHEP] as one of the official GlueX external packages. As such code that depends on CLHEP would be allowed as part of the standard build. Reasons for including it include:

• It is an essential building block of GEANT4. It is therefore common for experiments to require it. When we start using GEANT4, it will become a requirement anyway.
• Many of us are using it in current non-standard-build code:
  • Matt uses it in AMPTools.
  • Mark uses it in his least-squared track fitter.
  • Sascha uses it in Monte Carlo studies for eta decays.
• It is a relatively lightweight package, without a lot of prerequisites itself.

David argued against the proposal:

• We already have a lot of packages that are required. We should minimize their number.
• Much of the functionality in CLHEP is already present in ROOT and that is already a required package. So CLHEP is redundant.

Matt remarked that CLHEP has a much smaller code base. Curtis mentioned that using ROOT classes often incurs some ROOT-ish overhead. Mark did not disagree fundamentally with David's reasoning, but thought that we will from time to time find that introduction of a new package is necessary, that such packages should be considered on a case-by-case basis, and that this case is compelling.

Matt pointed out that we have some "typedef's" where, for example, a DVector is used in the code as a proxy for TVector. The idea is that the underlying code that supports such classes could be changed without changing GlueX code. He wondered whether we should change the underlying code library from ROOT to CLHEP, where appropriate. In this case, we recognized that simply changing typedef statements was unlikely to work, that full wrapper classes would have to be written. That would mean that initially we would not have "package purity" but would depend on a mixture of ROOT and CLHEP classes.

David stated that he would not die if we adopted Mark's proposal. The Chair then declared that [??? consensus] had been reached and the proposal was adopted.

Software Review Preparations

no committee, no charge friday weekly meetings matt, eugene, curtis, david, mark in communication with clas12 curitis: understanding among ourselfsv swereh we wstand what has to be done what manopower will it take where are we thin Rolf leading effort ot get collaboration between halls meeting planned for a week from today next wed. 14, 3:30 division level meeting halll leaders meet, graham selected topics online systems halld will not focus on the online as a planning strategy some assignments from rolf done tracking clara vs jana to do

	single event display

monitoring histograms

Reconstruction Subgroup Reports

Calorimeters

Extra Clusters in the FCAL

Will described further work on understanding extra clusters in the calorimeter. For plots and details see his wiki page. He has put aside the BCAL for now and is looking at FCAL photons in b1pi events.

• He reviewed the note from Mijailo??? on FCAL reconstruction.
• He looks separately at photons that convert before the FCAL and those that don't.
• Reconstrcution efficiency for non-convertors above 1 GeV is 98.6%.
• There is a big drop off in efficiency below 400 MeV.
• He will check the definition of an unconverted photon: does it includes photons that convert in the TOF?
• He made two changes that reduce the number of extra clusters:
  1. Allow a charged track to veto more than one cluster.
  2. Increase the matching radius at between charged tracks and clusters.
     • There is a bug that causes the run-time parameter to be ignored.
• This more agressive matching reduces average photons per event, he thinks it is due to hadronic showers causing multiple clusters over a wider area.
• Paul volunteered to implement Will's two changes in the default code.

More Realistic BCAL Hit Generation

David described recent work he has done to output waveform hits from the BCAL. This is done in mcsmear. It is not the default scheme at present. One of the goals is to realistically model the inclusion of dark hits, which seem to have a surprisingly large effect on the timing of real hits in the default scheme.

The data model changed some time ago to accommodate the new data. The pulse is built up by histogramming, in time bins, energy deposition in the BCAL. Updates are weighted by energy and attenuation is taken into account. The resulting data is then used to extract the threshold crossing time.

With these additions, mcsmear runs 15 times slower and events are 50% bigger. Curtis thought that for specialized studies this approach is valuable but wondered if it was necessary for the standard work. Work is on-going.

Tracking

Simon described work he had first mentioned at the last tracking meeting. He is addressing the problem of closely spaced tracks. See his wiki page for plots and details.

He looks at track finding for events with decaying Λ's. The resulting vee's cause confusion associating hits into segments and extra track candidates result. He is playing with a simple algorithm, where segments that share a large fraction of hits are flagged in pairs and one can be rejected based on the amount of hit sharing and the relative χ² of the segments from a circle fit.

He has also looked at K_S's. Mark suggested that crossing tracks would be another interesting configuration to test.

PID

Paul reminded us of the [??? email] he sent yesterday on renaming, restructuring, and reorganization of some of the reconstruction classes. The changes have been checked into a separate branch, and although they compile, the new names break some of the other code, for example hdview and phys_tree. He solicited help in making the rest of the tree consistent.

Beni volunteered to look at hdview.

On an unrelated note, Will suggested that we save the co-variance for neutrals at the shower level, not at particle level. Paul intends to work on this.

new release

consensus new one now

TDR

old TDR had a pwa section, offline software, general philosophy, high level summary of software, look at what was in there in 2004. David volunteers to look into it.