Core Minutes 3/20/2012ScienceTools: (Jim) Two bug fixes went in recently and an enhancement, now in HEAD, to the ScaleFactor class which will be useful in model selection when models are not nested. See Science Tools Development Notes for details and a link concerning model selection.
FSSC: (Eric W.) is finishing up with v9r27p1, resolving some issues on snowleopard. (Tom S.) For Data Server the recent big project has been to ingest data with the new diffuse response. Alex (new guy) did most of the work.
(Heather) Richard is in the process of getting a lion box for us. What has your experience with lion been over there? (Eric) I have nothing to report. There is only one lion box here and it's over-subscribed.
MySQL migration: (Heather) Everything is ready to go except for OpsLog because the responsible person (Tony J) has been out of town and unable to test it. However we could take care of the databases destined for mysql-node03 (that is, calibration and the mood mirror) and move the glastCalibDB alias, now that we know how the mirroring is being controlled. (Joanne) discovered to her surprise that the mood mirror was being updated only about once a day, so probably by a cron job. But everyone at SLAC disclaimed responsibility for setting it up or any knowledge of how it was done. I finally resorted to asking Navid. He didn't remember anything about it either, but was nonetheless able to guess the answer (cron job run from glastrm account).
Pass8 news from F2F, Collaboration Meeting: See presentations from the Face to Face meeting in Confluence (Leon) The new truncation scheme has been tested. There were no disasters, but people were surpised to see data rate go up by 30%. This was due to CNO triggers. They tend to have a lot of junk, which causes a buffer overflow error. Furthermore, current fsw handling of such an event is to send it down with little or no compression. (Tracy) believes it will only take a parameter change in one of the CDMs (data-like module) to fix it. (Leon) is debugging the code which converts new-style events to look like those with the old truncation scheme so as not to upset L1.
(Leon) Our current overlay scheme is:
This seems like it might not be sufficiently random. We originally just picked each overlay event randomly, but it caused disk thrashing. Leon is looking for a happy medium: e.g., use a limited number of overlay events sequentially (chosen to be compatible with various buffer or cache sizes), then pick a new place to start.
(Heather) was asked by Phillipe to make a new Pass8 GR tag, which she duly did. However it has a large failure rate. (Tracy) detected a problem in new code in CalClassifyAlg which would cause a memory leak and may be the source of the failures. In any case it should be fixed.
Recon news from Collaboration Meeting: (Tom G.) We've been doing MC production remotely at Lyon for some time. Now we're seriously looking into porting Reprocessing there as well. It's more difficult because of the dependence on databases and so forth. It may not be ready for the current reprocessing; maybe the next time around. See discussion of these topics on the Computing Splinter Confluence page.
(Leon) Alex Drlica has developed a new set of ACD pre-filters for Pass8 which are significantly more effective. Downstream pre-filters can now be retuned on the new, photon-enriched set of events.
The big reprocessing task: (Tom G.) It's moving right along. 2260 runs have finished out of a total of 20,000. At the current rate we should be done around mid-May. We routinely use 1200 to 2000 cores. This is all fine but it does impact user jobs.
Systests (Heather) is eager to get systests going for SCons builds. Liz has not been accessible recently. (Leon) It's especially difficult and error-prone dealing with systests when we have to deal with different branches for different runs. (Heather) fears this will be the norm for some time to come.
SCons RM error handling (Tom S.) has implemented the improvements discussed last week:
So far we can say the changes haven't caused any new bugs. We can't say any more because the error conditions with the improved handling haven't occurred.
Installer and GR (Tom S.) It has been impossible to fetch GR builds with either the command-line orthe gui installer. The immediate cause is that a particular db entry, the one for the user release, isn't there. In fact the user tarball is not getting made successfully (the source and developer tarballs are ok). And that's because the tar command is looking for and failing to find a syspfiles directory which exists only for ST. There already is some code in there which attempts to distinguish what kind of build it is, but it's coming up with the wrong answer. [Late update: Tom analyzed the problem further and is in the process of making a fix.]
GR vc90 (Joanne) is waiting on a new, truly debug build of CLHEP. It seems we will need a complete set of debug externals and ultimately, if there is a need for optimized builds, a complete set of optimized externals. (Heather) will see about concocting one. Only non-debug optimized binaries are distributed, which is a mite disturbing. Why doesn't anyone else care about this?
New SCons version (Joanne) installed the current production release, 2.1.0 on her Windows desktop some time ago and has been using it. It seems fine. It has also been installed on SLAC Linux but is not the default version (still at 1.3.0). You can find it at /afs/slac/g/glast/applications/SCons/2.1.0/bin/scons. Especially since most recent changes to SCons have been to Windows-only code, chances are excellent that the new version will behave just like the old on Linux but that hasn't yet been tested.
VS Externals (Heather) will get started on rebuilding a debug CLHEP for vc90 since it seems we have to have it — and perhaps debug versions of several other externals — to make any forward progress. (Joanne) CLHEP, like geant, is especially critical because it has static libraries rather than dll's. We might be able to get away with an opt. version of some of the dll externals.
|
|
minutes index
|
next
|