Core Minutes 3/07/2006  

Participants: B.Giebels, A.Borgland, I.Pavlin, J. Cohen-Tanugi, J.Chiang, J.McEnery, R.Dubois, T.Usher, T.Burnett, T.Glanzman, N.Golpayegani, S.Digel, D.Chamont, H.Kelly, D.Landriu, L.Rochester, W.Focke, C.Patterson, D.Flath

Muons penetrate Pipeline!

• Recent runs from actual cosmic ray muons formatted with official Flight Software have been processed through the Pipeline. There were some problems (run/eventId missing; context info) but generally successful. Heather has gotten most of the problems solved, one detail of the context is still being studied. Flight s/w is Linux only; a subset for Pipeline operation is being studied/massaged to build on Windows via cygwin.
• CCB issues will be addressed soon (today?) to catch up on recent surge of activity.
• Richard and Leon, who will be in Pisa two weeks from now for a beam test meeting, propose a new "Beam Test Release" for the occasion. The idea is to insulate the beam test from rapid GLAST Releases and instabilities (and vice versa) much as the Engineering Model works today. The problem is branching which complicates the periodic synchronization of the code. Michael Kuss to be recruited as the new "Anders/Heather" for this new release.
• Muon cosmics to continue being collected today and beyond...

Fallout from last week's DC2 kickoff

• Kickoff meeting viewed as successful. Initial reports reveal no fundamental problems!
• Need to pick a date for a new Science Tools release. Today(?) Process takes 2-3 days, but bugs (and fixes) continue to dribble in. RM currently not enabled to work automatically for Science Tools, but is scheduled for this automation after some details are settled. Navid will try automated build for next release.
• Recent permissions problem on V: drive associated with upgrade has now been resolved.

GLAST Release v8 status

• GR-v8r0 built and looks okay, but problem building on Windows (some libraries needed for development did not build properly[??]).
• A Windows build complication concerns dependencies. When building against a given .dll, everything that dll required when it was built is also required. Would like to understand/fix this.
• New Geant4, Gaudi, and ROOT5 ready. New CLHEP is biggest challenge; should merge branches sooner rather than later. New lib policy requires some further work - to get some attention this week from Navid and Toby.

New Version of CMT

• New CMT CVS plug-in ready to use, and compatible with CMT v1r16 (version currently in production). Waiting for green light to go forward. CMT checkout command will change. Must demonstrate success of this plug-in before moving to CMT v1r18 and its bug fixes (e.g. CMT broadcast cmd)
• Set up Confluence page with GLAST's CMT problems so David can present them to the CMT developers. This becomes more important as GLAST considers replacing CMT with an alternative (see below).
• David is given green light to put new plug-in into production (old version can be put back quickly if this becomes a problem), everyone with an interest should try to test this ASAP. He will do this immediately after the meeting.

** NEWS FLASH**

Abandon CMT?

• Scons (Python based "software construction tool"), is Toby's suggested candidate. Toby and Jim have been testing this utility. This would be a major change to the GLAST software infrastructure. Some tools, like MRvcmt, would break.
• Tests: Jim has built some packages successfully. One implementation involves a config file to each and every directory containing source. Jim suggests we develop the use of Scons in parallel with CMT; demonstrate its success and eventually phase out CMT. Richard is uneasy with this proposal. Others counter that this is the natural way to bring Scons into the fold. [Subsequent comment from Jim: "I will continue to develop it in my user area with the aim of eventually having a full ScienceTools build via SCons. At that point, I reckon we can revisit the issue of folding it into RM builds."]
• Two other issues. Equivalent of $CMTPATH for automatic package search. Equivalent of "set" command to setup execution environment.
• Is the Scons development organization stable and here to stay for the long haul? According to their web page, they've been at it for five years already. Should be further investigated.

previous

minutes index

next

T,Glanzman Last Modified: 01-Jun-2010 15:45:46 -0700