Minutes Day 1 - Monday

• Riccardo provided a nice introduction to G4Generator. We discussed v1, v1r1 does not seem to work due to a problem in the gui package. The main components of the G4Generator package include: 
  • RunManager - handles the Geant4 event loop so that Gaudi's event loop is dominant 
  • PhysicsList - uses the Physics list (with just EM no Hadronics) from Geant4 Example N03 
    • Riccardo will try the Physics List from examples 4, 5, 6 to include hadrons. 
  • DetectorConstruction - interface to detModel Work for this week includes storing the Hits in the Gaudi Transient Data Store (TDS). 
    • Riccardo plans to use a digi algorithm for testing the retrieval of the Hits data from the TDS.
• Currently the instrument package is used by G4Generator to provide digitization and IRF capabilities. It is felt that this duplicate of the geometry is contributing to the slow start-up of the G4Generator application. It remains unclear how long the instrument package will be used by G4Generator. This is a question for Toby, and will be discussed later this week.
• On windows, it was noted that when using CMT v1r10p20011126, one should use GaudiSys v7r1p1.
• G4Generator is not a proper checkout package, since it does not specify the tags for GaudiSvc. The group wonders why not? A question for the package owner.
• Linux, CMT, and tkrApp Alex provided a demonstration of checking out and compiling tkrApp on linux (RedHat 6.2), using CMT v1r10p20011126 and gcc 2.91. The checkout and compile succeeded. While waiting for the compilation we discussed some CMT and gcc issues: CMTPATH - what is its function on UNIX? It seems that CMT's behavior on Linux is inconsistent - if a set of packages already exists within the CMTPATH, and one performs a CMT checkout, those packages already available within the CMTPATH may or may not be checked out anyway - and may or may not be compiled. On Windows, VCMT takes care of this by using the "uses" to determine which packages to checkout. How should we deal with this behavior? Do we want the group.cshrc to setup the CMTPATH? It seems that this becomes outdated rather quickly. This topic was set aside for further discussion later this week.
• Our official gcc compiler is still 2.91 (which works with all of our software and Gaudi v7 and v9). For those users of RedHat Linux 7.2, where gcc 2.95 or 2.96 is the default, it is necessary to use gcc 2.91 - called egcs on RedHat 7.2. Alex is available to aid those who need to obtain the proper version of gcc. It was noted that as the SLAC norics are upgraded to RedHat 7.2, the gcc 2.95.2 installation is "broken". If one uses egcs (gcc 2.91), the GlastPolicy requirements file must be updated in order to use it. The group wanted to find a better solution, such as modifying the CMT requirements file directly to use egcs. Again this topic was set aside until Toby is available for consultation.
• The group wondered what version of gcc we will move to in the future. Gaudi will be upgrading its compiler support in the summer, presumably to 3.0 or 3.1. (editor's note: in speaking to Charles Leggett - he felt we are best advised to move to 3.1 when released - it is believed to be more stable and provides faster compiles and smaller executables).

H. Kelly Last Modified: 2002-03-05 11:55:11 -0800