Core Minutes 2/27/2007

• All hail! (Richard) Upon her return, Heather will be crowned Queen of Infrastructure.
• Making up for CMT deficiencies: (Toby) [but paraphrasing heavily and I hope not incorrectly. ed.] CMT does not handle custom build steps properly on Windows. We have one for invoking rootcint and another for generating the full list of public symbols for (non-Gaudi, non-component) shareable libraries. Generally speaking CMT does a poor job with the build process on Windows and we have had to make up for it with extra logic in MRvcmt. It seems best to handle the entire build process outside of CMT, but continue using CMT for remaining functions such as managing the package list. To this end, Toby has written Python scripts to handle builds. (Richard/Tracy) Tracy independently tracked down the bug in CMT which was preventing proper extraction of global variables from the output of dumpbin, and hence proper functioning of the linker_library pattern for those non-Gaudi shareables containing such variables. (Toby) If he had known of Tracy's work, he might not have started down this path, but it does have other advantages. (Joanne) has never much liked CMT but would still prefer to incorporate Tracy's fix and think long and hard before making radical changes in our build infrastructure.

  See also the discussion of this issue in the Infrasoft mailing list.

• GlastRelease externals and RHEL4: (Navid) has managed to compile Fred on RHEL4. He still needs to build some third party libraries that Fred depends on. That work is in progress — or was shortly after the meeting. Here is the very latest news from Navid:

  I have just enabled the RM to build GR on rhel4_gcc34. I expect many compile errors. I'll be keeping an eye out for problems with the external libraries. Feel free to email me about RM problems you notice with the GR builds on rhel4.

• Interleave: (Tracy) is about done with checkout of what we have to date; it seems fine. His next task in this area is to figure out how we can interleave real background data rather than having to generate it with MC.
• Python versionitis: (Tom) got involved in the subject when he requested the maintainers of the SLAC-standard version to apply a patch to the logging module and was told there was no central support. He soon discovered different groups within SLAC used different installations:
  
  

  Group	Where	Version(s)	Supported by
  SLAC central	/usr/local/bin/python	2.4.1	Not supported by anyone except for security updates
  Group K	/afs/slac/g/ki/bin	2.4.3	Paul Kunz? Includes large collection of modules, one of which is hippodraw.
  Flight software	Private machines at SLAC and GD-Spectrum Astro	2.4.x at GD,  2.5 at SLAC	Tony Waite/Jim Panetta
  I&T Online	taylor installed in I&T workgroup	"gpython" using modified RedHat RPMs, version 2.4.1	Selim Tuvi
  ISOC	ISOC-OPS machines	2.4, 2.5	Bryson Lee and David Decotigny
  SAS	GLAST_EXT	2.4.1	Navid Golpayegani? Jim Chiang?

  This motley collection suggests the following questions:

  • Which installation should be used for GLAST pipeline development?
  • Which installations are and will be actively supported?
  • Which installations can be patched readily without large delays?
  • Which installations can be upgraded without huge delays and red tape?
  • Which installations are (or can be) visible to all of SLAC?
  • Can (should) the GLAST project get by with fewer installations?

  [Thanks to Tom for providing a written summary—no way could I get all this down on my own. ed.]

• Geometry: (Joanne) Work on spacecraft geometry is finally showing some fruit. The 8-sided cylinder below the LAT represents the spacecraft primary structure. It's not too interesting yet because I don't have a total mass for it (or, equivalently, thickness and density). It won't take long to add some of the other requested components, such as fuel tank and contents, for which I do have complete information. However even this minimalist picture points up the glaring absence of LAT electronics: TEMs, GASU, etc. Richard suggested Mike Huffer as a possible source; he referred me to a delightful spreadsheet which lists all the electronics boxes under the LAT, along with dimensions, position and mass, making it possible to quickly incorporate them into the model. (Leon) It's important to get the material constituents and their distribution correct. (Joanne) For this I need more information than what's available from the spreadsheet. Cabling is also omitted. The spreadsheet lists a total mass but says nothing about position. For now for the electronics boxes I made a family of materials, all made of equal parts copper + aluminum + silicon, with the densities needed to get masses to come out correctly. (Richard) recommends talking to Ken Fouts. (Joanne) Since some mass numbers for real spacecraft components are still missing, she'll  make an xmlGeoDbs tag with old spacecraft, but adding the LAT electronics modules.

previous

minutes index

next

J. Bogart, Last Modified: 01-Jun-2010 15:48:02 -0700