Announcements: (Richard) The announcement of the new name for SLAC is now scheduled for tomorrow. Apparently it was postponed from the original date of Oct. 1 until a suitable logo was designed (same thing that held up announcement of Glast --> Fermi).
Overlay: (Tracy) has rudimentary digi merging working for CAL and TKR. He had a long discussion with Eric Charles about ACD. Eric agreed to do much of the work needed for ACD, following Tracy's design.
Tracy ran into a snag while working on the CAL digis: the overlay data needs to be pedestal-subtracted using the appropriate calibration, not, in general, the same calibration required by the MC data being generated. For Tracy's current work, he's using the ideal calibrations for MC. Because these aren't looked up by the calibration infrastructure [and because of a fortunate choice of when to do what in the design of the overlay processing - ed.], the calibration infrastructure does "the right thing" in this case. But it won't work in general, when the MC data also requires non-trivial calibrations. For the current exercise he will use ideal calibrations for MC and will get to work on the next step: selecting the overlay data bin. Longer term we should think about applying calibration(s) to the digis before merging them in. (Leon) Even if we solved the 2-calibration problem (which is a technical issue which could presumably be handled somehow), there is still a performance problem with trying to apply calibrations to the overlays in the same process doing the MC: the sequence of overlay events will not all come from the same calibration era, in fact it's likely that there will be lots of swapping back and forth. It would be far preferable to merge in a form of data which is not calibration dependent. (Joanne) The "2-calibration problem" is really a "2-timestamp problem": we already can access multiple calibrations of the same type by use of flavors as long as all calibrations are valid for a period including the event timestamp. The expectation of a single timestamp during processing or generation of a single event is deeply embedded in Gaudi calibration services as well as in our home-grown calibration infrastructure. Designing something more general would definitely take some time. Without going through that exercise, it's hard to know if it would also involve a lot of recoding/refactoring, but I was not planning on spending any time on such a design because of the likely thrashing as overlay data wander among different calibration eras. I also vote for (ultimately) doing preprocessing on the overlay digis so that they are calibration-free.
Ghosts: (Leon) The ghost-identifiying and displaying code is now available so people can get some experience with ghosts. The harder part of the project — figuring out what to do about them and then doing it — remains. He can't yet estimate how long that will take.
GR updates: (Heather) r48, including all Leon's ghost updates, is out. r49 will have some ROOT-related improvements.
The new LDF will probably show up in r50. There is nothing in it to our immediate benefit, but upgrading to it involved some work in ldfReader because the interface changed.
skimmer: (Leon) Harking back to overlays — probably will need to run skimmer first. He and Robert have been having problems running the command-line skimmer unseen by others. He's gotten some suggestions from David Chamont, but, so far, no luck with them. (Heather) The symptom is it's not finding the commonRootData library, even though it does in fact reside in a directory included in the path. That library is not referenced directly, but should be loaded because another library using it has been requested. She has not yet been able to reproduce the problem.
ScienceTools: By the time we got to ScienceTools in the meeting, no one was around to give the report, but you can read it for yourself.
Documentation: (Chuck) said and then sent the following:
It's been a while since I reported, so I'll try to catch everyone up-to-date on some of the not-so-routine updates to the workbook as succinctly as possible:There's a new GBM/GRB tutorial from Analia and the folks at Goddard; this was incorporated into the Science Tools section of the WB prior to the collaboration meeting. In addition, I've made a few changes to the HTF pages in Confluence; the most recent was to the HTF Tomcat Servers page. A copy of the 'How to Fix' pages from Confluence has also been exported to the WB as a backup, and these HTF pages are now backed up on the mirror site as well. However, a new tag is needed for the WB in order to bring the mirror site up-to-date with the latest changes. The WB HTF backup pages can be accessed from a link located just beneath the top image in the right column WB's splash page.
Jim Chiang updated the pyLikelihood tutorial and also pointed me towards two additional examples; these have been incorporated and posted to the web.
Late last month, Richard, Heather, Julie, Nicola, and I met in EVO-land to identify what additions and changes need to be made to the new Science Analysis section of the Workbook. The highest priority is to develop a new iLat Tutorial, starting from Gino Tosti's tutorial and Eduardo's tutorial, both of which currently reside in Confluence. A version for SLAC Public is nearing completion, and could be linked in to the WB as soon as we get the setup.csh script updated with the current production version of the Science Tools. I'm currently working on a high-level overview for iLat and the evolving recommendations for what constitutes a "standard analysis". Next up is to work through the normal issues to create desktop installation versions of the iLat tutorials and document additional examples, and to identify and document the iLat parameters.
Core week (Heather) Add your thoughts to the topic list in Confluence.
Python external, RM [Thanks to Navid]
I've been working on re-installing python 2.5.1-gl1 for all the linux OSes (rhel3,4,5). Progress was slow until now because I had to create virtual machines for each OS and perform the compiles there. SLAC's /usr/local interferes with the build of python particularly with zlib compilation. A clean install on a virtual machine prevents that problem along with new problems such as blas and lapack libraries that are installed by default at SLAC. There was a problem that Tcl/Tk's webpage wouldn't let me download the source code to compile python against it. This is necessary for rhel3 since the default version of tcl/tk is 8.3 and we want to use 8.4. This issue has now been resolved with Eric Winter's offer to give me the packed up source code of tcl/tk that he happened to have. I have now compiled python and all of the modules for rhel3,4,and 5.On the Release Manager side I have now compiled all the RM code with Qt on both rhel5 and windows. They are all ready to go except for a small problem with the rhel5 boxes. Currently, the way they are configured they lose afs tokens when a job is submitted via lsf. This is a problem since the RM code is located on afs along with the external libraries. I've contacted the SLAC admins about this issue and they are looking into it. Once that issue is resolved I'm fairly certain the compiles can start since I can perform compilations from an interactive ssh session without problems.
External libraries (Emmanuel) On RHEL3 he's built SciPy and NumPy. For Windows, Python 2.5.1-gl1 is now installed on the V drive. He needs to install NumPy, PyFITS, etc., against it and has run into an extra wrinkle: the system wants to install them against the version of Python in the registry, which is the wrong one.
(Heather) has run into a problem related to the new OmniOrb. When she tries to start Fred using the new OmniOrb, it can't load FOX. [(Joanne) has some experience with a similar situation on RHEL4 — at least the symptom was similar — and ultimately managed to get Fred going by rebuilding a bunch of stuff. The trail has grown cold, however.]
GoGui (Joanne) has been working on two GoGui-on-Windows projects:
previous | minutes index | next |