Present: Bill, Francesco, Heather, Joanne, Karl, Malcolm, Riccardo, Richard, Toby, Tracy, Tune
Pisa Meeting: (Riccardo for the Italian Group) The following topics concerning use of G4 with detModel for geometry input for GLAST were covered:
writing XML files for balloon and test instruments in order to use
a G4 simulation with detModel for data analysis and physics validation
Recon use of detModel -- needs query interface
producing "real" hit output from G4 application. So far can write an
ascii file or a Root file, but the Root file is in a custom format,
not the format used in other GLAST code.
need for a mechanism to describe sources, probably in XML. (Toby remarks
that there is nothing gismo-specific about the way this is done in
production code now, using an XML description of sources. Should still
be usable with G4 as the simulator.)
G4/Gaudi integration; there is an agreement to form a small task force
of people, coordinated by Bari, to address the problem
Core Report: (Toby) See Toby's writeup. It includes, among other things, a plan of action for the main topic of today's meeting: G4 integration (see below).
PDR work is being impacted by memory leaks. They can make it impossible to run long jobs. MSDEV tools for examining the heap have been dusted off and are being put to use.
New Recruits: (Richard, Karl) Our third masters student has been hired; Karl has been helping all three get going. One has relatively substantial C++ programming experience.
G4 Integration Discussion: The discussion was mostly in response to some email Richard sent a couple days ago. Several issues were touched upon:
Infrastructure: (Toby, Heather)We need to get the version of G4 the Italians are using imported into CVS and lay the groundwork for it to be an external package.
Simulation for I&T: (Tune, Richard, Riccardo) Tune would like a way to use the new flexible geometry with G4 for I&T work by the end of the month(!). (Richard: end of month is not realistic.) For example perhaps Riccardo's stand-alone G4 visitor could dump the geometry after detModel reads it in. Then another G4 application could read it in. Riccardo says this could be done, but this is not the way the visitor operates now. Current paradigm is for an application wanting access to the new geometry to link to the detModel code and use detModel access services. [ed: An advantage of this approach is that all the information in the XML file is accessible via detModel services. Standard G4 formats have no place to keep track of segmentation, identifiers or any other things Riccardo and I have put in beyond bare description of volumes and their positioning.] Richard suggested that if Eduardo & company need a way to do simulation on that timescale they use gismo. Tune was assured that we will not support both simulation programs indefinitely.
Segmenting logs: (Tune, others?) Don't forget about it. This is being done in current G4 (for balloon?) MC.
Simple G4 Application: (Toby, Riccardo) Toby would like to see a little G4 sample program which gets a very simple geometry from detModel and produces (Root?) hits output. Riccardo will look into it.
G4 Workshop: (Richard) A G4 workshop will be held at SLAC in February. We've been asked to present something about what we're doing with G4.
J. Bogart Last Modified: 06/01/2010 15:45