Attendees: Joanne Bogart, Anders Borgland, Emmanuel Cephas, Jim Chiang, Richard Dubois, Tom Glanzman, Navid Golpayegani, Tony Johnson, Heather Kelly, Chuck Patterson, Leon Rochester, Tracy Usher, Eric Winter
Going back over our to do list for the week..
Reprocessing status
Had a meeting on Wednesday via EVO. Tom reports that there is a prototype job that starts from digi files. This prototype breaks runs into chunks and does not yet merge. That is on the to do list. Tom plans to look into the skimmer's merge utility for this purpose. Tom was wondering what merging tool is currently used in the pipeline. Will use xrootd for merging. Warren has had troubles with AFS, so after Tom checks on the failure rate with xrootd, Warren may do the same. Tom, Tony, and Karen discussed bookkeeping issues and what to store in Oracle. Next up is to create the tables and the interface.
Skimmer
Tom reported on the current status. There are a variety of reported skimmer problems. David Chamont is just leaving for vacation until early August but did offer some work-arounds for the current issues.
1. Julie reports a crash with 100 merit ntuples, which Tom can reproduce with the command line skimmer v6r1 and v6r0p1. Julie had reported seeing memory usage in the 3GB zone, while Tom recalls nothing over 400 MB.
2. Patrick Smith using v6r1 on a rhel4 machine reported failures. Tom was successful using the skimmer on rh9. This problem seems to disappear when using the v6r0p1 version of the skimmer.
3. Simona had trouble extracting recon events. Tom has not had an opportunity to look at that too deeply.
The web interface for the skimmer continues to use skimmer v5. Tony reported that he can see from the logs that there are many users. Richard asked about the failure rate. There have been no reported problems, but Tony will go back to the logs to see if there are unreported problems.
Python Distribution
Jim had sent out a request for reports of python distribution problems. There were just a couple responses, so for now this issue is tabled. Eric W asked what plans there are to move to python 2.6. Jim said it is under consideration. Navid requests that we remain at python 2.5.1 until Red Hat catches up.
SCons
After our meeting on Wednesday, Navid reports that he has checked in a series of SConsript files for some GR packages into CVS. He can now build and run some test applications on Linux and Windows. For those that may like to try this out, check the SCons Confluence page . Replace ScienceTools-scons with GlastRelease-scons. Navid is currently using scons 0.98.3 in the new RM, and has tried out scons 0.98.5. Both versions are installed at SLAC.
Next, Navid will teach Emmanuel how to proceed with the updates, and Emmanuel will take that over from here on out. This allows Navid to focus on the new RM and MRScons (name TBD). Navid has started to talk to Tony concerning issues about the new RM. Concerning the need to scope out the issue with JO files - Navid has decided to start the environment variable conversion and while doing so, take a look at the JO files in the affected packages.
Joanne and Navid have had some discussions concerning the new MRScons. They have agreed Qt will be used. Richard asked to be sure that Qt is now freely distributed for windows - and it is now.
Compiler and O/S Support
Mac - Navid needs to put in a new request to install LSF on the two available Mac machines at SLAC.
RHEL5 and gcc4: Richard will look into obtaining some RHEL5 machines
Navid asked how much longer will we support 32 bit? For some time 
GlastRelease Status
v15r25 is tagged and includes the EBF updates to grab EBF blob from evt files and provide it to OBF.
Fred Piron had reported on his attempts to compare MC to data and had discovered some discrepancies. Tracy now fully understands that issue. In MC, in OBF, we run the filters through all stages, while in real data only a subset is utilized. Tracy is working making sure both MC and real data are run in the same fashion. Tracy also suggests that we create a new algorithm that will continue to run as the MC does now, using all bits.
TkrRecon and G4Propagator crash
Leon has looked in depth at one of the events causing a G4Propagator exception. At least on windows, this event doesn't terminate - however, Leon does see that the track reconstruction is a bit crazy. (The Zorro event), where it is understandable that the propagator cannot handle. The plan is to catch the exception and zero out the TKR output. This has the side-effect of making this event look like a CAL-only. Tracy and Leon both point out that this is rare. Joanne suggests that we should have some error word available in the ntuple and the recon ROOT files to denote problem conditions such as this. We should not have to just rely on the log files to determine that something went awry.
new GlastClassify tag from Leon is available, however, Bill has since spoken to Tracy concerning a discovery about some CAL energy cuts, which when an event fails, some variables are left to their initialized value such as the CTBParticleType variable which is set to zero (which also denotes a gamma). Tracy wants to move these cuts into the IM XML Analysis so that Bill can set the initialization values as he desires.
Random Overlay
Coming soon to a GR near you...
Richard mentioned that Philippe came by his office earlier and suggested it would be helpful to have a library of real events to draw from, which we could "overlay" onto an MC event. This may help study pile-up issues. Currently we are able to overlay noise, but the concept of overlaying an additional digi event from a ROOT file onto an event is new. This would certainly require some tweaks to RootIo and as Leon mentioned, some modification to TkrRecon where it gives preferential treatment to the highest hits, which in this case, may not be what you want.
Workbook
Chuck has updated the FRED documentation online to provide a better description of how to use the event display. In attempting to install FRED on a new windows box, Chuck ran into some terrible problems. It turns out the issue stemmed from using the current release on Ruby (1.8.6). When Chuck down-graded to 1.8.2, suddenly FRED functioned again. There are other reports on Linux, where users need to use 1.8.6 versus some older versions of Ruby. This makes it rather difficult to document how to get FRED installed. Chuck requests that we consider providing Ruby ourselves, to insure users grab the correct version. This is straightforward on Windows - it is not so clear what version of Ruby we should distribute for Linux.
FRED and Wired
Speaking of FRED... we are giving some consideration to moving to Wired as our sole event display. Some things need to happen first however..
Users of FRED should evalute Wired and make sure it does all that we need it to do.
Tony and Heather need to provide the ability for Gleam to start up Wired just as we currently do for FRED.
Addendum - Other Computing Issues
- ownership of TriggerAlg
- Martin will cede stewardship shortly. There will be a meeting of interested parties on Tuesday (July 15).
- recon seems very slow!
- Tom & Warren are seeing 2.5-3 Hz when reconstructing data runs. Ground muons used to be ~15 Hz. What's up?
- need to keep track of disk resources
- L1Proc seems to be munching xrootd disk at 2-3x the budgeted rate. Probably will recoup the "extra" when we purge superseded L1Proc file versions.
- We need to develop tools to keep an eye on xrootd and Oracle space used.
- Access to Data
- we should turn off ftp-glast access to u31 and u33. We will be asking the same of data transferred away from SLAC.