Core Issues/Status 06 March 2002

Previous status report; Joanne's meeting  minutes   

CMT v1r10

TS now converted.

gcc 

We are happy with 2.91 and will stick with it, thank you very much! On the low norics, e.g. noric02:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

However,  on the high norics, e.g. noric10:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)

VCMT, VC++ 7.0, Visual Studio .Net

No change. Matt Langston, respected expert on compilers, tells THB that it is the best compiler he has seen. No independent confirmation.

THB presented a discussion of vcmt to the CMT workshop. A lot of interest in our customized workspace.

Gaudi v9r0

Heather ready, but we will wait for the G4 transition. (See  below).

GLAST software development environment issues

• The current situation stinks. Other CMT sites recommend that we adopt the LHCb  scheme, which is a tiered approach using CMTPATH to point to folders for:

• system (like Gaudi, external packages): rarely change
• stable (packages not under development, long time span)
• shared (packages that are being rapidly developed: weekly update of this?)
• private (user's space: new copies of shared packages, that are then put into the shared space)

Questions:

• how are these sets defined? Probably via special packages. Need to examine LHCb stuff in detail.
• how do we impose this structure on all the personal workstations/laptops? Unlike LHCB or ATLAS, few of us develop in a shared environment. Perhaps tar files or rpm's.d
• what is a "release"? Presumably a tagged version of the description for stable and shared set of packages.

Note that adopting this would avoid problems we have with the multiple, non-overlapping, "checkout packages".

• ChangeLog and tag/rtag:

Pat Nolan has (with probe by Heather) reminded us of this situation. Basically, the mechanism to update ChangeLog with the rtag information exists, but needs a scripting expert to wire it up to our requirements.

Here is a record of the failed attempt.

G4 transition

Core meeting decision was to quickly implement the following:

• detModel geometry description with mm units and new coordinate origin: also to completely encapsulate the detModel classes in the GlastSvc service GlastDetSvc.
• Convert to  MeV  energy units..
• hit classes and corresponding digi algorithms replace instrument versions.

Some consequences:

• Frozen packages:  GismoGenerator, instrument, gismo, heavy. Will not be in future releases. No manpower to convert and support them.
• New package: Recon, to encapsulate gismo stepping for IKalmanParticle implementation, and GUI detector display: checked in as v0.
• G4Generator will no longer support instrument stuff, detector or hit displays in the GUI.
• All instrument and IRF related stuff to be removed form GlastSvc.

What about plans to make a detailed Gismo/G4 comparison?

• CDR will use G4, can compare final results on A_eff and PSF, background rejection.
• IT plans to validate G4 with beam test data
• If really needed, GismoGenerator can obviously be converted later.

T. Burnett Last update: Wednesday, 04. August 2004 15:42:08 -0700