Present: Deepu, Heather, Janani, Joanne, Leon, Madhup, Marco, Riccardo, Richard, Tracy
US LHC Computing Review: (Richard) See his notes. There are several items which merit further investigation for possible use within GLAST, such as new improved (non-blob) Root converters, a tool for enforcing coding rule compliance, and a software analyzer called Ignominy.
Doxygen: We need to set policies and standards for content. All packages should have a mainpage providing an overview of package functionality and how it fits into the general scheme; many already do. Similarly every class needs some meaningful description of its function. With regard to Doxygen comments within a class two points need to be stressed:
Comments are necessary for any member whose purpose or meaning is not clear, including descriptions of method arguments when not already self-evident.
Screen space is a valuable resource! It is acceptable, even preferable, to leave uncommented any declarations which are truly self-explanatory.
Heather raised a separate Doxygen issue: what to do about release tags when the only change has been to the Doxygen documentation? It's tempting to slip the new files into the old tag, but in other situations this has proved to be risky practice. No policy decision was reached (yet).
Core Issues: (Toby) See details in his report. Mostly it concerned the considerable progress which has occurred recently in G4Generator and, in order to support it, in detModel.
Timings are looking good: both GismoGenerator (using detModel) and G4Generator are taking about 3 seconds per event, if anything a little faster than the gismo simulation using the old form of geometry input.
Tracker BFEM/BTEM support in the G4 environment will wait until G4Generator is fully operational and RCParticle or equivalent is available. [The new tracker recon depends on RCParticle which in turn uses services from gismo.]
Installation of both CMT v1r10 and Gaudi v8r1 is on hold until after PDR.
News from SCS: (Richard) A couple items:
We now have a group account for batch submissions, etc. Access to it will be controlled via acl.
We have been asked to try out the Hierarchical Storage Manager. Testbeam data would seem to be a suitable place to start.
Reports from our students:
Janani has been doing a trade study of bug-tracking alternatives Bugzilla, Remedy and Gnats. Gnats is probably inadequate for a project of GLAST's size; the other two are still contenders. Soon her report will be publicly available.
Deepu has been working on an Oracle database to be used by the Data Manager, for example to keep track of its state.
Madhup has an automated procedure for producing a web page displaying amounts of disk space remaining in various GLAST public pools.
J. Bogart Last Modified: 06/01/2010 15:47