Core Minutes 9/18/2012
Core Minutes 9/18/2012SeeVogh: Some are attending today's EVO meeting via SeeVogh. Linux users tend to have problems with it, but not in all cases. Tom S. is using it successfully from Scientific Linux 6, 64-bit. Joanne's redhat 5 machine is probably a lost cause; the video driver (which works fine for everything else) has been deemed unacceptable. Those who can use it have some issues with the interface. Richard has sent some questions and requests to SeeVogh support.
ScienceTools: (Jim) There is a new patch tag, ScienceTools-09-30-01 to pick up sane fixes and a new SolarSystemTools tag. Since then there have been several fixes and enhancements, most recently one concerning leap second handling. See Science Tools Development Notes for details.
FSSC: (Alex) Focus has been on importing the new ST tag; it's going well. We are ready and waiting for new pass 7 data, now due to arrive in December.
Tom S. has been spending most of his time working on the port to Mountain Lion.
Reprocessing: (Tom G.) Eric C. says IRFs for Pass 7 will be ready soon, at which point we can begin reprocessing.
nfs partitions (Tom G.) Last week's move of 13 nfs partitions to wain26 went smoothly.
Hardware (Tom) Installation of the 450 Tbytes of new xroot space is imminent.
(Richard) There will be a meeting tomorrow with PPA to discuss the compute cluster. Expect decisions and actions to follow shortly thereafter.
Black boxes (2000 cores) are about to be shut down. For one thing, Oracle is no longer supporting them (has not been for the last 6 months). For another, with the new purchases there will be a shortage of redhat licenses.
There was a paperwork glitch in the recent order of stand-alone Linux boxes (10 for us, 2 for another group) so it has to be redone.
pass 7, Pass 8 (Leon) There is a problem in the CAL calibration system so that it does not pick up a new calibration when the event timestamp moves outside the validity interval of the current calibration of a particular type. This has only been confirmed for MC runs. (Joanne) The underlying calibration infrastructure was designed to pick up new calibrations as needed. If CAL is not doing this it's a bug of some sort; e.g. perhaps cached information is not being refreshed when it should be. When it behaves correctly, there will be information in the log indicating that a new calibration has been fetched. (Leon) will look for this in data runs where new calibrations ought to be fetched. [He has determined that CAL is not behaving properly for real data processing either, at least not for Johan's job which reconstructs 130 GeV events.]
(Tracy) The ROOT upgrade Heather is working on should go in before the next (around Oct. 1) release of GR for Pass 8. (Heather) She's working on it. She'll try it first for Pass 8, then L1 and ScienceTools.
Core talk:
WIRED (Heather) Dima is now set up with GlastRelease 20-05-00 on Windows 7. He is working on addressing outstanding Wired JIRAs. He ultimately had to install VS 2008 in order to get things working.
Pass 7 branches (Heather) needs to complete merging the truncation code off the "old" Pass7 branch into the new RHEL5 supported version off the current L1proc GR 17-35-24-gr35 in support of the P7 MC folks and Leon working on truncation code
Skimmer problem (Heather) encountered by Bill is under discussion in JIRA FDH-31. She may have to try running in the debugger.
lsf replacement candidates (Tom G.) There are three, none of which supports all three platforms (Linux, Windows, Mac) of interest to us. If virtualization were handled in a reasonable way that would provide a work-around. (Tom S.) Some conversion work on RM will be necessary with any change. If we're lucky it will just mean changing one command line for another. The lack of support for some platforms is a separate matter. We don't need to run that many jobs. It might make most sense to wrap the programs which do builds, etc. with scripts and do our own scheduling on unsupported platforms via cron jobs.
(Tom G.) There are no real batch experts (as opposed to batch users) on the task force.
The prime motivation for ditching lsf is to save money, but, when you add in the cost of conversion and possibly increased maintenance costs, it's not clear it will save money. In any event, some decision will be made fairly soon. (Richard) The lsf license is due to be renewed in March (which doesn't necessarily mean a decision must be made by then).
Mac (Tom S.) is unable to build the current (5.26 and change) version of ROOT on Mountain Lion with the native compiler. It's almost possible to run Snow leopard builds there. The only problems have to do with one or two python modules. (Heather) has at times heard talk about upgrading SLAC machines to Lion (not Mountain Lion), but not recently.
SCons RM (Tom S.) Generally it's working well, but the two annoyances of previous weeks are still with us. still with us:
Windows developer environment (Joanne) is close to done with the minimal set of improvements needed for typical use of a supersede area on Windows, with or without Visual Studio. See last week's minutes for a description of what needed to be fixed. The code needs a little more wringing out, then I'll commit and tag. Some things are still not handled correctly, fall-out from the change to non-installed headers:
Beyond these hard, but probably irrelevant, restrictions, potential Windows supersede users should be aware that this is not going to be a terribly friendly environment. There may be times when the behavior will seem irrational. It isn't, but you'll have to understand something about how SCons works, when project and solution files get created, etc., to make sense of it.
Virtual machines (Heather) Hasn't yet had a chance to try GR Standard, but is wondering: what is the plan for upgrades as we come out with new GR versions? (Joanne) For bare-bones, my expectation was that it would primarily be used on a Linux host with all the usual tools, such as Installer, available. The user could pick up a new release with the Installer and share the folder with the guest OS.
For GR Standard, especially if the host OS has a different file system, you probably want GR and associated externals on the guest's (virtual) disk. They still can be fetched with the Installer, but disk space on the guest OS is limited. For GR itself, one can delete the old version, install the new, and the disk space usage will be similar. For externals this is not necessarily the case because the externals in GR Standard have been hand-pruned. They are noticeably smaller, sometimes a lot smaller, than the same externals as presented by the Installer.
Calibrations also have to be considered, now that we are in a regime where new calibrations are regularly created. GR standard comes with a set, but that isn't necessary. Even in cases where the host is not Linux calibrations can be kept on the host in a shared folder, but there still is the question of exactly which calibrations are needed (not the whole of the archive in SLAC's $LATCalibRoot; that has all kinds of extraneous stuff) and how they get updated.
previous
|
minutes index
|
next
 |
J. Bogart, Last Modified: