Core Minutes 9/9/2008
Core Minutes 9/9/2008GR updates: (Heather) The new LDF is almost ready to go. There were some interface changes causing it to take longer than it otherwise might. After one last patch from Eric C. for AcdUtil trapezoid geometry should be ready, but this has to be confirmed first by C & A. Two new fsw releases are on their way: B1-1-1 and B1-1-2. The first involves GRB updates and shouldn't involve much action on our part. The second has changes to the gamma filter which will require some work on our side. (Tracy) [thanks to him for the following post-meeting summary. ed.] FSW 1-1-1 really only has new Cal pedestals and gains, so should be straightforward to integrate into our stuff FSW 1-1-2 will have fixes to the HE Pass problem in the gamma filter, this will mean a "V3" of the header files defining the bits in the status word, meaning the ordering will be different. This will require a bit more effort to deal with.
ScienceTools: Jim went over the weekly report.
RHEL5 (Heather) Are we getting any closer to having access to RHEL5 batch machines at SLAC? (Navid) In principle SCS has agreed to it, but the hardware is lacking. He believes Richard is looking into purchasing a couple machines.
Reprocessing (Tom) There is a working prototype! It has been used successfully to reprocess a pair of runs multiple times [for validation of trapezoids], which has served as a rehearsal for the impending reprocessing of August data. There are still some loose ends, particularly having to do with bookkeeping. New versions of tools (e.g. xrootd, skimmer) are helping with this and also have taken care of other problems. Status is summarized in this Confluence page.
More on skimmer (Heather) David C. would like to keep the master copy of the skimmer code in a SubVersion repository where he is rather than our CVS repository at SLAC; the skimmer is not really specific to Glast. We would still have access to the code in its new home. We treat it as an external, so keeping the source elsewhere is not expected to cause any problems. Please speak up if you think it might!
New RM, SCons (Navid) The release manager stuff has all been rewritten to use Qt. The lsf submitter, and the workflow have been tested. The checkout step is fully working and the the compile step is mostly working. I have run into a snag with the release manager daemon that's responsible for various tasks such as submitting LATEST, HEAD, and release builds. The unix-admin folks don't want me to run trscron jobs that run longer than an hour. The daemon needs to run longer than an hour. I've been going back and forth with the unix-admin folks trying to come up with a solution. The problem is that an AFS token is required for the daemon to obtain some passwords stored in a file on AFS. [Thanks to Navid for providing this paragraph. ed.]
(Heather) What is the state of the web interface? (Navid) Karen's interface is currently pointing to an earlier version of RM. Among other changes, the new one is using a SLAC-centrally-maintained MySQL database. He will speak to her about changing over to the new one; most likely it will not involve a whole lot of work.
(Emmanuel) Over 60 GlastRelease packages now build with SCons. The remainder depend, directly or indirectly, on external libraries which have yet to be installed according to the new organization. Once this installation is done, ability to build the remaining packages should follow quickly. (Heather) would like to convert CMT requirements files to also use the new organization.
(Joanne) has been working on SCons performance within GoGui. There is substantial overhead when SCons starts up, especially on Windows where file i/o is slower, because it reads all files to determine dependencies. In typical interactive use these dependencies change only rarely, so SCons provides an "interactive" interface: from a shell window, issue the command scons --interactive and you get an SCons-dedicated process which will not re-check dependencies for subsequent requests. GoGui now makes use of this, but in a simplistic synchronous fashion so that the gui is unresponsive during the build. There actually isn't a whole lot that a user could usefully do during a build anyway, but there are a few things, including ability to abort. A new version in which builds run asynchronously should be done shortly. As always, see the GoGui Confluence page for current status. (Heather) What about builds on Windows? (Joanne) One can use GoGui to build with SCons on Windows, but SCons, with or without GoGui, does not yet produce Windows project and solution files. That will probably take some combined effort from Navid and me; it's on the list.
Externals (Heather) Several upgrades are coming soon, including OmniOrb, Tcl/Tk Python library and maybe ROOT 5.20. See a Confluence page on the subject for details.
Ghost tracks (Toby) Much of the C & A meeting
yesterday was spent on "ghost tracks", an issue which should have been
foreseen and handled in our software, but wasn't, so we have to do something
about it now. (Heather) missed the
meeting. What's it all about? (Leon, Tracy, Toby)
The tracks in an event come from
a longer time interval than the trigger window and may include accidentals not
associated with the trigger. In practice a non-negligible
fraction of our events (>= 5%, depending on raw trigger rate) include such ghost tracks
and hits. This affects calculation of
IRFs. We need to do at least one of
It's a substantial amount of work in any case and overall strategy is still under active discussion. 2. will require a major rewrite of pattern recognition, but Bill has pointed out that many of the primitive "knobs" needed to handle this are already implemented: gap-counting, searching for hits before the track, etc.
If we try to remove ghosts, we will have to deal with ghost CAL energy as well, which implies some type of clustering.
previous
|
minutes index
|
next
 |
J. Bogart, Last Modified:
01-Jun-2010 15:47:16 -0700
