Core Minutes 9/27/2011

• ScienceTools: (Jim) found a place where gtsrcmaps can return some memory earlier, thereby reducing peak usage by about a factor of 2. See Science Tools Development Notes for more information.

• FSSC: (Eric W.) has been working on the web interface to the database; others at FSSC have been looking into gtsrcmaps.

• Pass7 reprocessing: (Richard) No news on the "how" front. (Leon) Our current "pass7: merit files are actually the result of a pass6 reconstruction and a pass7 event classification. In addition, the original (only) reconstruction was done with pre-launch CAL (important) and TKR (less so?) calibrations.

  At last week's (Sept. 22) Pass8 EVO meeting, Art Snyder's presentation "Effect of re-calibration on PSF" showed evidence that some combination of real pass7 processing and better calibration constants seems to have a noticeable (and salutary!) effect on certain crucial distributions. In particular, slide 6, showing CTBCORE (remember this was the big shocker when it was finally looked at in pass 7), and slide 7 showing a stand-in for PSF.

  Johan is currently doing a series of reprocessings of Art's AGN dataset: original calibrations, new TKR, new CAL and new both, to figure out who is responsible for the change. Once they're done, Art can do his skims and presumably just push the button on his analysis.

  (Tracy) But keep in mind that time spent improving Pass7 is likely to delay Pass8.

  (Leon) There is a new tag on the v17 branch, v17r35p24gr07. Heather had asked for systests so he tried to comply — it was a disaster! Some jobs crashed immediately. Others exceeded the batch queue time limit. He might try some things by hand. (Heather) has hope there may be some relatively mundane cause for all the problems, perhaps having to do with attempting to maintain comparable release tags for CMT and SCons builds.

• GR/Pass8 (Tracy) New GR is coming (Heather) that would be GR v19r3p9. She will put it up on the UW terminal server when the build is complete. (Tracy) has been finalizing tree-based tracking; Bill is improving classification.

• Documentation: (Heather) Heather continues to make small modifications to the existing workbook and loves Tony's new Hudson test builds and ability to make the new version "go live" with one little script.

  Last week, Richard had noted that some images were missing in some workbook pages, such as the description of Confluence. It turns out that the jpg images in the workbook were inconsistently named *.JPG and *.jpg. This was find on the windows web server, but now that we are using the unix server, this causes the files to be deemed "missing". Tony has already updates all the actual image files to consistently use *.jpg as their naming convention. Heather went over the whole workbook with a "find and sed" command to update all occurrences of *.JPG with *.jpg and committed it back into CVS. This is now up in the test site and will "go live" later today. It looks good, but if anyone notes any missing images, please let Heather know.

  Richard is working on getting some feedback on what web design tool to use, so that we may more easily handle future larger updates to the workbook, including adding new pages and content.

• Core talk:

  • Long-term RM support (Heather) At the moment, we support both CMT and SCons RM, where we hope to ultimately support just SCons RM soon. Still, Navid left a big hole, and we live in a world where mysteries continue to pop up and one might ask how we intend to care and feed these systems for the life of the mission. Tony Johnson has mentioned the Hudson build system and it seemed worthwhile to ping Tony about what would be involved in our migrating to Hudson for our builds. Heather outlined what we have now, our use of LSF, the need to support Linux, Windows and Mac, all our various "add-ons" like the red-dot summary, parsing of the compilation output, providing an upper level summary of the build results, etc. Tony responded and Hudson does sound customizable. At the moment, Hudson would have to be taught how to start up builds in response to tags. LSF is not supported, rather Hudson would use its own daemons which runs on our various OSes, including Windows. We could create support for LSF, but that would obviously entail some work. At the moment, this doesn't sound like a worthwhile pursuit, as much work will be involved in recreating the system we already have. Admittedly we do need to consider how to best support the RMs for the life of the mission and perhaps the time that would have been spent migrating to Hudson, could be better spent documenting what we already have. Jim would like to consider starting up some Hudson builds to allow us to pursue that angle and slowly build it up to do what the current SCons RM and web interface does now. Discussion ensued.. more to come at tomorrow's SCons meeting.

  • Nagios crying wolf (Heather) Normally it is a good idea to pay attention to complaints from Nagios, but there has been a spate of spurious ones recently, probably indicating there is a problem with Nagios itself.

  • obf (Joanne) hadn't heard anything about a new version of certain flight libraries, so poked JJ late last week. As of this meeting, she hadn't gotten any response [but did immediately afterward: a new version is ready for us to try. And it works!]

  • Data-like externals for the Installer (Joanne) The new externals, catalogProducts and diffuseModels, were not being packaged up for the Installer. Tom S. pointed out that RM decides what externals to package up based on output from the SCons build which lists externals. Externals with no load path or binary path had been excluded (presumably for some reason, but no one knows what it might have been). Joanne changed the logic to list all externals and all externals are now available and known to the Installer.

  • Windows builds (Tom S.) They quit again, for an unknown reason. He checked the registry keys used to store RM configuration and they were still there. He will try switching to use a file (as is done on unix by default) to store information rather than the registry. He would have gotten to this sooner except that glast-win04 mysteriously crashed and had to be rebooted. (Heather) Although we expect this to be a rare event, maybe we should go back to having an old Windows box or two available as back-up. (Tom) That is difficult, since the the old boxes are 32-bit and the new one is 64-bit. That means that certain information is kept in different places. RM as currently constituted can use one or the other; supporting both at once is not easy. [Soon after the meeting Tom put the new code to use configuration files into production.]

  • VM for ScienceTools development (Toby) describes progress and problems here. (Joanne) It's not surprising that these kinds of problems arose. Fedora 15 is not that close to RHEL 5: different kernel, different compiler. In the past we have not had much success with using non-native compilers on Linux systems. (Tom S.) RHEL5 is comparable with Fedora 9. He is sympathetic to the desire to get the benefits of the most advanced OS version, but Red Hat's mission is to provide stability and support [and SLAC is somewhat further behind in that RHEL6 was released last November. RHEL5 was released in 2007]. (Richard) SCCS is abaout to make a RHEL6 test batch queue. (Tom G.) Machines are available now for login. Use alias rhel6-64.slac.stanford.edu; there will be no rhel6-32. (Tom S.) Even rhel6 uses an older compiler than Fedora 15. rhel6 uses gcc 4.4; Fedora 15 uses gcc 4.6. [See e.g. the Wikipedia article on the relationship between Red Hat and Fedora releases.]

• Announcements

  • SCons meeting this week at 10:30 on Wednesday.

previous

minutes index

next

J. Bogart, Last Modified: