ScienceTools: (Jim) Went through this week's report.
FSSC: (Eric W.) Getting ready for the coming ST release. (Richard) The new data class could mean a factor of 10 more events. Will this be a problem for the data center? (John) we should be able to handle a factor of 10 more since we did have nearly that much in the pre-pass6 data.
Documentation: (Chuck) sends the following:
The generic pipeline and pointlike are priorities #1 and #2. The gtgrb Tutorial also needs to be updated to include SCons builds, which can be done rather quickly as soon as I can verify that they no longer cause a failure when running grbAnalysis.
GR Pass 7: (Anders) Eric C. has been concentrating on looking for internal consistency in addition to comparisons with Pass 6. Results are very promising. See his C & A presentation from Monday for details. He will continue this work with the likely result that a decision will be made at Saclay whether to move forward to Pass 7 or not.
We haven't yet made Pass 7 FT1 files with new irfs or livetime dependence.
GR Pass 8: (Tracy) Activity at Santa Cruz and at SLAC is focussed on track-fitting problems. At Santa Cruz they're looking into implementing a third recon pass, using best energy. (Leon) Robert is working on an idea to look for tracks which originate near struck ACD tiles or near the edges of the LAT in general. This is to try to identify cosmic-ray tracks which may have been missed by the current patrec algorithm. Meanwhile he (Leon) continues to look at alignment; not much to report yet.
(Tracy) expects the meeting this Thursday will spur another round of activity>
(Toby) has a sabbatical next year, starting in September. He hopes to spend it in Santa Cruz, helping with the Pass 8 effort.
User disk problems: (Richard) there have been reports of problems accessing u54/u55 via WinSCP (Toby, others) and also of other anomalies which may stem from the same cause (or maybe not). They tend to occur when the disk is in heavy use. SCS suspects an OS patch from last November. They will back it out next Tuesday, and they recommend new hardware. Meanwhile, it would be in everyone's interest to avoid beating on the disk as follows: [from Richard's email]
The main way is to minimise traffic to the disks by using the batch machine's /scratch partition to good effect:For those running the Science Tools, there are issues with .par files.... For further instructions see the Workbook on this topic.
- copy input files to /scratch at the beginning of the job. (Warren further suggests using a private subdirectory of /scratch, e.g. named after process id. Process id is accessible as $$ in bash/tcsh/perl or os.getpid( ) in python.)
- do all work on the batch machine with no disk traffic outside
- copy output files back to the user disk
- clean up /scratch (it is not done automagically)
ROOT and Gaudi (Heather) Root 5.26 is, from her perspective, ready to go. It's in use in LATEST. She will promote to HEAD once she has an all-clear from Pass 8 developers and from Jim on behalf of ScienceTools.
As for Gaudi, she has been paring it down as much as possible. Work has so far primarily been done on Windows.
rhel4 opt (Heather) We had a good RM build on Feb. 4, but all subsequent ones, starting with one on Feb. 11, have failed. They appear to be submitted to the wrong queue and with the wrong options. Kim found the following in the log of a failed job:
bsub -E "/u/gl/glast/infraBin/bsubChange.pl Started 1831455" -r -G glastgrp -R linux32 -q long -o '/nfs/farm/g/glast/u15/tempBatch/1831455.log' '/u/gl/glastrm/ReleaseManager/src/linux/compile.pl' ScienceTools-HEAD1.792-rhel4_gcc34opt 2>&1Queue should have been glastbldq and -R linux32 should instead be -R linux40. Kim is scouring RM database tables and scripts for any clues on how this could happen.
SCons exception bug (Joanne) has found a way to fix the problem Jim saw — in the case of shared but not dynamically-loadable libraries, do not include libraries on the link line — and even has a vague idea of why it works. After confirming that Windows needs different treatment, she committed and tagged changes for about 50 ScienceTools SConscript files. However builds are now broken on mac; apparently the mac linker needs those dependencies as well. It would be better to isolate the platform-dependent behavior to avoid having to change and tag so many packages.
Meanwhile I've been spending evenings and weekends summoning demons.
SCons report from Tom He successfully turned off SCons rhel3 builds. He continues to work towards the goal of understanding why user/dev/source releases aren't always getting made or, if made, are not always getting registered in the database.
64-bit Onboard Filter (Tracy) would have to take some time to relearn the subject before he could embark on this. Other work has higher priority. (Richard) believes Gregg might be willing to work on this; we should ask him.
previous | minutes index | next |