Difference between revisions of "GlueX Offline Meeting, March 7, 2012"

From GlueXWiki
Jump to: navigation, search
(CLHEP)
(CLHEP)
Line 63: Line 63:
 
* It is a relatively lightweight package, without a lot of prerequisites itself.
 
* It is a relatively lightweight package, without a lot of prerequisites itself.
  
tvector dvector, clhep
+
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.
 
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.

Revision as of 18:44, 7 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
  8. Review of recent repository activity: all

Communication Information

Video Conferencing

Telephone

To connect by telephone:

  1. dial:
  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

will, put aside bcal, looking at fcal photons in b1pi events where are extra photons coming from start from note from mihailo on fcal reconstruction looks at photon that convert pre-cal and not reconstrcution eff for non-convertors above 1 gev 98.6% efficient big drop off below 400 MeV definition of unconverted: includes tof extra photon problem only allow one cluster per track match hadronic showers give multiple clusters allow multiple clusters to vbe vetoed

the match radious made wider more agressive matching reduces average photons per event,

paul will implement wills two bullets

bcal work, not default data model lchanged, can write out energy weighted time spectra, light as a fucntion of time, pulse shape simulation, extgract threshold crossing time mcsmear runs 15 times slower, events 50% bigger record down to kev, record as a string discussion at collaboration meeting, need for realism,

Simon tracking

from tracking meeting, issue with track finding with decaying lambda, vee's, confusion of assositona of hit setnemts, extra track candidates simple altorigthm for dealing with this problem puts all hits into bit patterns compare bit patters, if too many hits in common, trigger algorithm

pid, paul

email yesterday on lifesaving cosmetic changes to pid checked into separate branch, renameing things Dcharged track hypothesis some code is broken hdview broken beni volunteers fir hdview will suggested covariance for neutrals at shower level, not at particle level incorporate

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.