Core Minutes 12/14/2010

• ScienceTools: (Jim) In the past week there have been three new tags of Likelihood, incorporating a bug fix and two enhancements. See the last three entries (starting with the one dated Dec. 8) in the Science Tools Development Notes for details.

  There will be a new release of ScienceTools this week, probably tomorrow.

• FSSC: (Eric W.) has been porting v9r18p6 to new platforms, specifically several OS versions of Ubuntu and Fedora Linux.

• Documentation: (Chuck) sends the following:

  The Newsletter is priority #1 for the week, and is on schedule. I've also echoed the 'Alternate Mailing List' in Google space, and will also echo it in the Workbook later this a.m.

• Pass8: (Tracy) There is nothing specific to point to; work on reconstruction is ongoing. In preparation for the Face-to-face in February, planning to make a release this month and launch a production runs in January. This will leave some time for Bill et. al. to look over the data before the meeting.

  Still outstanding is the question of when to upgrade to a newer G4. The technical part (handling interface changes) is easy enough; we're hung up on validation because the designated validator is seriously overloaded. For the January runs we'll most likely still use our current version but we do need to get moving. (Richard) Are there things we want in the newer version? (Tracy) Yes, there are some useful improvements. Besides, we could have problems as OS's advance if we don't upgrade. It's too early in the life of the project to freeze on this version.

  (Leon) is looking into fixing failures in GR SCons builds. So far, he has learned more about how to break things than to fix them.

• Pass7: (Richard) There is a request on the table for (ultimately) about a year's worth of background statistics to better understand cosmic ray backgrounds. cpu resources required are in the vicinity of 2000 cores for 5 years. We own 1600 and have some access to the others in the farm, but can't expect that kind of priority for such a long period.

  (Leon) They're trying to combine things (e.g. overlays with older code that doesn't know about diagnostic info) that haven't been combined before. Whether this will cause problems is TBD. (Tom G.) would like confirmation that random numbers will behave properly for such large datasets.

  (Richard) Change-over to Pass7 for L1 is coming. Tom has about 6 months of catching-up to do. Then we need to make FT1, etc. Once we switch over data volume will be about 10 times current.

• Core talk:

  • Disks (Richard) We have about 50 TByte remaining and another 75 we could get by cleaning up. The Computer Center might be able to loan us another 60. However, we're in hock to KIPAC (who will probably bear with us until we manage to purchase something) and BaBar (who might not).

  • TMine + SCons + Windows = headache (Joanne) has been wrestling with this since late last week. The fundamental problem is that the command line generated by SCons for creating the "def" file (and probably also for the link, but I've never gotten that far) exceeds the maximum allowed. Strategies attempted so far are arcane, but not quite effective. If all else fails, Eric C. has suggested the library (containing about 150 modules) could be broken up. There already is a natural hierarchical organization within TMine.

  • Time limit (Tom S.) A test program in ScienceTools failed in HEAD and tagged builds but was successful in LATEST simply because he had neglected to increase the time limit for the job in the first two categories. This now fixed.

  • Missing log files (Tom S.) It's a resource problem. All log files from both RM's are going to the same table. It has a disk allotment of 4 Gbytes. The table is pruned (already enough to be inconvenient when investigating a problem) but, even so, it is often full. We could try to increase the allotment or to direct output to two or more tables instead of just one.

  • Snow leopard build failure No progress since last week; working assumption is that the problem has something to do with libf2c. (Eric W.) Note that Snow Leopard will build 64-bit by default, even on a 32-bit machine; 32-bit has to be requested explicitly. One has to be careful that all application code and all externals are built 32-bit on a 32-bit machine.

  • New Windows box (Heather) For various reasons the plan had evolved to include two virtual machines resident on the one new fast box which would access data via virtual network disks. Tom was concerned that we might end up with slower access than our current arrangement: slow boxes but no virtual layers. Therefore we requested a return to something like the original idea: run Windows Server 2003 on the box; no VMs, no use of network disks except for the minimum needed to get completed builds over to u35. The Computer Center has agreed [and as of this afternoon had most of it in place].

  • SCons meeting Wednesday at 10:30, as usual

  • Start and stop times (Warren) There is a proposal to change the source for run start and stop times stored as metadata with files in the data catalog. Currently, they are read from a database which is populated by the HalfPipe and are double precision. The proposal is to read them from the event file headers where they are stored as integers, truncated, so we'd add 1 second to the stop time to be sure all the data were in the specified range. The values in the DB have been converted from MET to UTC and must be converted back before we can use them, and leap seconds make that troublesome. Are there any objections?

previous

minutes index

next

J. Bogart, Last Modified: