Present: Joanne Bogart, Sasha Chekhtman, Johann Cohen-Tanugi, Richard, Dubois, Marco Frailis, Riccardo Giannitrapani, Traudl Hansl-Kozanecka, Heather Kelly, Michael Kuss, Leon Rochester, Alex Schlessinger, Tracy Usher, Karl Young
Toby in Udine: (Riccardo) See this summary of the work done. There was discussion of some of the items.
McParticle tree: It may be that we will additionally want some mode inbetween the two now supported. Right now only e+ e- events are treated specially by the reduced mode. One could save a bit more information for an enumerated set of other event types. Another alternative would be to keep the full tree in the tracker (where it is most useful and also not that large) but not in the calorimeter. In the new G4 release it is possible to accomplish something similar by setting different cuts in different regions.
McTrajectory: Are we sure these objects shouldn't also have a persistent form?
Something like McTkrStrip has existed all along. Putting it in the TDS permits the digitization process to be split into stages more cleanly. Richard wondered whether something analogous might be done in the Calorimeter.
Relational tables: (Marco) Richard expects that most queries will come from user code: userAlg or ROOT analysis. Marco will consult with Heather about persistence of the tables. Marco will blaze the trail by implementing the first relational table in CalDigiAlg - relating CalDigis to McIntegratingHits. This has to be done in two sections of CalDigiAlg: the first where the signal is accumulated; and the second where (new) noise hits are added. Leon will cast an interested eye over how this is done towards the TKR analogue.
Random number generator: (Karl) After some research, he has a proposal for a design and for testing to see if it meets the (not quite pinned down) requirements. To be determined:
Can we be sure we'll get "good" random numbers if, as proposed, the seed(s) is(are) reset at the start of each event (most likely based on a formula involving run number and event number)?
Do we need 2 or more separate streams or don't we? [maybe not independent of outcome of above. ed]
Impact on existing code. Would like to minimize disruption.
Clean-up proposed: (Traudl) The Event package contains unnecessary and unused code which should be excised. GlastSvc would also benefit from some scrutiny.
Builds: (Alex) Nightly builds are running. He plans to divide up the work into 3 scripts: one for the actual builds, one for running test programs, and a third to generate html pages containing the results. As an alternative to the last, one could use CGI scripts to generate pages dynamically upon request, if SCS, traditionally leery of CGI, lets us.
FITS work: (Heather) Has quickly created a new package, fits2Root, primarily for the use of Gary Godfrey's student, who needs to read FITS data from ROOT. It is derived from some old beamtest code which provides just a basic interface for reading in arrays. Soon (week or so) we expect to have access to all of cfitsio from ROOT, courtesy of James Peachey (GSFC), who is working on such a thing for Integral.
Software test plan: (Richard) A draft document is now circulating. The scheme involves a relational database to track test results.
Delta PDR: (Richard) Coming up Tuesday-Thursday next week. We are responsible for a 1 hour summary talk on progress since January. We also need to be prepared to give some technical details in a less formal setting. Will keep in mind that the reviewer is a tracker guy.
Core week: The next one will be Sept. 9-13 at SLAC. Subject still to some uncertainty, we're expecting to have 3 code reviews: ACD software, Calibration infrastructure, and GLAST use of Gaudi (basically Event and GlastSvc packages).
Action Items
previous
|
minutes index
|
next
|
J. Bogart Last Modified: 01-Jun-2010 15:46:02 -0700