Core Minutes 1 May 2012

Core Minutes 5/1/2012

Present: Joanne Bogart, Jim Chiang, Richard Dubois, Elizabeth Ferrara, Tom Glanzman, Heather Kelly, Leon Rochester, Tom Stephens, Tracy Usher

ScienceTools: (Jim)
- added some functionality at the request of Dark Matter group, so they could look for 130 GeV line
- Fixed bug reported by David Landriu
- Addressed Johann's request for internal documentation for FT1
See Science Tools Development Notes for details.
Pass7 reprocessing: (Tom G.) Now about 58% complete. If all goes well, could be done a couple weeks into June.

Wilko will be out of town on vacation for 3-1/2 weeks starting May 7th, which could pose a problem. On Saturday there was a disk failure which Wilko was able to diagnose, but there may be no one else with sufficient expertise and log-on privileges to do this. Tom and Wilko will discuss back-up plans before he leaves.
New hardware for old: (Tom G.) Discussions are ongoing about the possible repercussions of replacing many old disk servers with fewer more powerful machines and similarly for compute servers.

(Richard) 400 cores from the batch farm are also due to be replaced. Money exists.
Pass7 news: (Leon) The brouhaha concerning magnetic field variables in FT2 files continues. While investigating, Leon discovered that our model of the evolving magnetic field only evolves up to Jan 1, 2010. Since then it's been constant. Since the actual magnetic field changes by about 1% a year this isn't tenable; we need to continue extrapolating for another 5+ years.
Pass8: (Tracy) Heather is nearly done with the Pass8/HEAD merge. Developers have been holding off commits but are ready and eager to start up. We'd like a new tag by the end of next week.

(Leon) reminded us that Heather has asked the Pass8 developers responsible for the code to take a look at what is currently there. (Heather) worries she can't always make informed decisions on her own about what needs to be moved over. The only RM issue still to be resolved with LATEST is a minor one: failure of test_OnboardFilter at run-time, CMT build only.
Workbook: (Heather) Some time ago Tony J. set up an automated system (via Hudson) to build the workbook in a test area every time there was an update in CVS. It would check every 5 minutes. That was apparently putting a significant load on glastlnx05, so Tony shut it down. We don't need anything like that frequence; once a day would probably be good enough. (Tom G. ) glastlnx05 is the primary xroot redirector, so we can't afford to compromise its performance. Its DC load was about 30% (already high) with peaks every 5 minutes of around 85%.

(Leon) What is the ultimate operational model? We used to have Chuck to bug us and the end result was that the workbook was kept reasonably up to date [universal sigh for the good old days]. Without that, there is danger of a vicious circle: the workbook becomes less relevant so people tend to use it less. Problems are not reported so it becomes even less relevant... (Tom G.) Perhaps we could institute a Workbook mailing list to which people could report problems. (Richard) There is already a feedback link [which points to Chuck's now-dead SLAC email address]; we could redirect it. (Jim) would prefer that the information go to JIRA — the Documentation project (key = STDOC) would be a suitable destination. (Heather) There is more of a barrier, particularly for new users, to using JIRA. They could be discouraged from reporting problems. (Joanne) It should be a one-click process; if there is a way to do that with JIRA that would be fine.
GR validation: (Heather) Close to where we were last week. (Joanne) expects to corral JJ to discuss differences in OnboardFilter output, B1-1-3 versus B3-0-0, for HFC and MFC (Gamma is identical) in the next day or two. (Heather) SCons and CMT builds have identical OnboardFilter output when both use B1-1-3. ACD is also identical. There are some slight differences in CAL; she hasn't yet looked at TKR.
Core talk:
- DB migration: (Heather) Last week Arash made a test dbs on mysql-node03 for SCons RM. How do we confirm it behaves properly under 5.5? (Joanne) The only issues we discovered with other databases such as CMT RM concerned keywords added in newer releases of MySQL. Tom has already checked for this with SCons RM, so my inclination is to declare us ready for the move. (Tom S.) feels the same way.
- GR vc90 (Joanne) After beating my head against the wall for nearly a week, trying to get SCons to make an "all" solution file using the standard MSVSSolution builder I gave up and wrote a python script to do it. After limited testing (4 input package sln files rather than 100+), the output looks the way I think it should look. Still to do:
  - See if output is really ok; that is, acceptable to Visual Studio
  - Try it with the full set of package solution files as input and see how it performs
  - Get SCons to invoke the python script so that all.sln will get built automatically with everything else.
- Tagging glitches (Heather) There have been a couple recently:
  - Alex used stag to make a tag. The SCons-style tag was made properly; the corresponding CMT-style tag was not. (Joanne) The CMT-style tag is not stag's doing; it happens in a separate step.
  - (Heather) Josh made a pointlike tag with stag. To the best of his knowledge, there were no complaints from stag, but the tag was not actually made. (Joanne) From information in CVS it's clear that stag went through all the preliminary motions. In particular, it checked in properly updated versions of SConscript, release.notes etc. But there is no evidence it tagged anything. Without seeing the output from the command on Josh's screen we can't be sure what happened. (Jim) has observed Josh make a new tag, then immediately make a new HEAD. (Joanne) wouldn't recommend this. The various tagging protocols and CVS itself are not 100% robust; doing things too quickly tends to increase chances of collisions.

minutes index

J. Bogart, Last Modified: