Present: Heather, Joanne, Karl, Leon, Riccardo, Richard, Sean (briefly), Sasha, Toby, Tracy,
Core Report: (Toby) See Toby's status report. The bulk of it concerns the impending move to G4 (see discussion below). Other topics, briefly:
Tracy found and fixed the memory leak mentioned last week. Another one, seen earlier, has not reappeared since the fix.
Karl has run off a million all_gamma events with v7 of pdrApp.
Release v1r10 (by convention should be stable) of CMT is imminent. It has at least one feature, permitted privacy of use statements, which could be useful to us, so we will probably move to it soon.
Saving Releases: (Richard, Karl, Toby) SCS has suggested using AFS rather than NFS space for this. This has advantages from our point of view as well: back-up is automatic and we can control access ourselves.
New Recruits: (Richard, Karl) Our new scientific programmer is due to start on Nov. 7. The three masters students have quickly picked up the essentials of how we do things and are ready for some real work.
detModel News: (Riccardo) Refactoring is in progress. The new detModel should be available early next week. A new geometry browser application, to run on unix and Windows, is also in the works. It displays text about the geometry elements and constants and shows how they nest. Plan is to also display 3-d images of volumes in some future version.
Multiple Source Events: (Leon) From balloon data, it seems that multiple-source events are not all that infrequent. Do we have a way to generate them? [Toby: not currently.] Can we calculate the rate? Would require understanding characteristics of the trigger, hardware shaping time, and "real" clumping, as might occur during GRBs.
G4 Discussion: (general) Items related to producing a fully functional G4 simulation (most but not all from Toby's status report) include
A CMT package for Geant4, either an interface package to a pre-built external library or a package which will build from sources. In any case we need the G4 source (e.g. to fix bugs).
A new G4 client package analogous to GismoGenerator. Probably we start with an updated (to be consistent with refactored detModel) version of Riccardo's G4 visitor.
Connection of new package to existing FluxSvc package.
Strategy for handling sensitive detectors and declaring them to the simulator.We could consider adapting the existing instrument package, minus functions concerning detector persistence (handled within new geometry paradigm) and irf data format (use ROOT digi classes).
G4 has a Sensitive Detector Manager for registering sensitive volumes.
Heather is looking into Brookhaven's ROOT Service (for Gaudi) but is not especially optimistic that it will be suitable; it might give us some ideas.
We need to finish off ROOT hit classes.
Something to handle materials. Gismo simulation uses material name to look up corresponding PEGS4 file. Goal for G4 simulation is to define materials properties in XML (adapt format developed by ATLAS). The existing embryonic G4 visitor has hard-coded descriptions. It will do in the short term but suffers from lack of flexibility.
Workshop Agenda: Suggestions for topics, organization, etc., for the November Virtual Workshop are hereby solicited and should go to Toby. Here are some that came up already:
Data manager, etc.
Build and release policies
Presentation of aspects of current infrastructure: use of CMT, package organization, ...
Documentation. We're not making effective use of DOxygen.
Presentations and discussion to help us make informed decisions about G4 issues above, including at least handling of sensitive detectors.
See tentative schedule, etc., here.
J. Bogart Last Modified: 06/01/2010 15:47