Core Minutes 9/30/2008
Core Minutes 9/30/2008GR updates: (Richard) FSW 1-1-3 has been activated (but without draining the SSR first, which could be a problem) so the L1 Pipeline must be upgraded to use a compatible version of GlastRelease (v15r47p1). Anders is busy doing that now.
Now that the transition to the new FSW has been made, other updates which have been held off are imminent, including at least v7 of the LDF external and several tags addressing ghost tracks.
Another candidate is an upgrade to G4 to properly simulate the LPM effect. In case you're wondering what "LPM" stands for and what the LPM effect might be, Leon says:
LPM stands for Landau-Pomeranchuk-Migdal. At high energies, there's a quantum interference effect that suppresses bremsstrahlung, so that electron and photon showers take longer to develop. Geant accounted for the effect, but they got the calculation wrong: too large, so there weren't enough brems when they got done. For a while we left the LPM correction out, which gave us better agreement with the data, but now it looks like they fixed the calculation, so we should be using it again.
Real aficionados should also see SLAC Pub 6796.
(Richard) There has been discussion with the Cosmic Ray Electron group of updates to CRflux; no known resolution yet.
(Richard) When we implement the 10% solution, there will have to be something which writes out a minimal skeleton or marker for the cut events. (Heather) has already put some thought into this and has some ideas.
More GR news: (Richard) Any news on "silent" ROOT errors? (Heather) They probably have to do with AFS glitches. The merging code needs better error-handling.
(Tracy) has been prototyping and approach to the random overlay problem. The basic plan would be to create a new package, Overlay, which, in the spirit of the interleave package, deal with details of selecting randomly a periodic trigger event as the background of a simulated event. At this point, with the details of how to select period trigger events still to be determined, a basic package has been created with an algorithm which simply reads serially from a single file, in root digi format, of period triggers. The package's main algorithm reads in a single event after the event simulation (gen through G4Generator) and the input digis are stored in a special area of the TDS. To continue testing, first modifications have been made to both the Tracker and Cal digitization algorithms to merge digis from simulation with the digis in this special TDS section, with the resulting digis then deposited in the main Gaudi TDS, then everything goes off to reconstruction.
The results of prototyping to date indicate that the general scheme appears to be workable, at least for Tkr and Cal digis. More work needs to be done to explore integrating into the system before the Trigger step (which may have some pitfalls with the Cal) and then OnboardFilter, but it appears to be straightforward. [Thanks to Tracy for the above. ed.]
Reprocessing: (Richard) Tom has Reprocessing going for spacecraft alignment. There is some question of which alignment to use. Consensus is that the revised one is only ε better than the one now in production. Discussion is still ongoing about upgrading the diffuse response model.
[thanks to Heather for the following] Richard asked about the status of removing the need to read in digis to do the reprocessing. There are two issues:
Reprocessing Lite: (MERIT+DIGI) -> (MERIT+FT1)
[Here is a report from Tom,
even though he didn't get a chance to speak at the meeting]
25 runs have now passed the "Seth Test"
Display performance improvements: [Leon kindly provided the following report, more comprehensive than what was said at the meeting, concerning improvements he made to HepRepSvc. He hasn't heard back yet from Tony what happened when the new code was used by the display server.]
The problems are very long wait times for large events, and very big jobs on unix. The fix that took care of the long wait times was to pre-allocate memory for the subinstances of an instance (say TkrClusterCol and its TkrClusters). (Joe Perl mentioned this to me at some point, but I didn't pay careful enough attention.) This dropped the wait time for a particular test event from several minutes to 10 seconds.I was hoping that this might also help the big-job problem, based on not much except that perhaps the garbage collection was different on unix, and that all the resizing of arrays (or whatever) wasn't being properly handled.
The new code should improve performance for both WIRED and FRED.
Documentation: (Richard) There was a meeting yesterday to discuss improving the documentation for Science Analysis. The existing documentation could be improved to give new users a better idea of the scope of the tools. iLat should be recommended as preferred interface. See the minutes for more.
ScienceTools: There was no one to give an oral presentation today, but you can read the weekly report on your own.
SCons et. al. (Heather) There was a meeting last week to discuss status of SCons and associated entities (new RM, its web interface, GoGui,..). Would like to get enough of the pieces in place by Core Week (now confirmed as week of Oct. 20) for developers to try it out. See details in Heather's minutes.
SCons, RM Status [Thanks to Navid for this written summary] I've compiled all the rhel5 external libraries for ST in SCons format and I'll shortly begin SCons compiles of ST in rhel5. The obf external library has been restructured for SCons but there's a conflict in filenames in a few libraries. I'm talking to Tracy about possible ways to resolve this.
The new Release Manager is up and running and just needs a front end to display results.
SCons for ST has been modified to generate wrapper scripts for linux and windows.
I'll be sending an email about reorganizing the job options files for GR so that SCons can work with it. This was already approved a while back but I never got around to it. I'll send out an email outlining what I'm going to do. The procedure hasn't changed from when I initially got the go-ahead.
External libraries (Emmanuel) Now that OmniOrb is ready for SCons and obf, the other remaining external, is nearly so (i.e., reorganized as SCons expects them to be) he will try a full GR compile again. Much of the red on his status page should go away! You can see current status of third-party Python packages on this Confluence page.
(Toby) has two questions. What about Windows? And what about pyLab? (Heather) Emmanuel will be getting to work on Windows side soon. (Eric W.) pyLab is a matlab-like interface to matplotlib, already on the list. (Heather) Up to now, criterion for distributing Python libraries has been that our code uses them. Is that the case here? (Toby) pointlike (not officially part of the distributed ScienceTools, but still a science tool) uses scipy. (Heather) What version? (Eric W.) HEASARC distributes matplotlib 0.98.3. It does not distribute scipy at all, but does use version 0.6 internally. (Heather) Then those are the versions we should use.
(Heather) is modifying CMT requirements files as new versions of extlibs appear to use them in the new-style directory arrangement, to lessen, albeit only slightly, the jolt of moving from CMT to SCons.
GoGui (Joanne) Has modified GoGui's old ad hoc method of running programs to use the wrapper scripts. The improved SCons also generates a setup script which GoGui uses to bring up a terminal window and to bring up gdb in the correct environment to debug a program. See the GoGui Confluence page for the latest news.
previous
|
minutes index
|
next
 |
J. Bogart, Last Modified:
01-Jun-2010 15:45:50 -0700
