Present: Ursula Berthon, Joanne Bogart, Toby Burnett, Xin Chen, Johann Cohen-Tanugi, Richard Dubois, Dan Flath, Navid Golpayegani, Traudl Hansl-Kozanecka, Julie McEnery, Leon Rochester, Alex Schlessinger, Tracy Usher,
Memory leaks: (Navid) See his report on evaluation of methods to detect memory leaks in our code, mostly using Valgrind. It can be extremely slow (2-3 hours for just a couple events running test_gleam.exe!), but maybe we don't care too much. We can run it in batch and it probably doesn't take many events to turn up the large majority of leaks. Navid's recommendations, generally agreeable to the group, are:
use the older version of Valgrind, already installed at SLAC. It's slower than the newer version, but finds some problems the newer version misses. Also the newer version is new enough that it's somewhat buggy.
first run it on package unit tests. It won't be as slow and it will be easier to sort out the problems seen and assign responsibility for fixing them.
Many of the leaks turned up are in our external libraries, especially G4. Some are even in system libraries. Output tends to be repetitious.
Leaks are categorized as "definitely lost" (memory has been allocated but all pointers to it are gone), "still reachable" (typically memory that has been allocated once and not returned at the end of the job), and "possibly lost" (meaning unclear).
There are various graphical front-ends available for interactive use of Valgrind.
Background event run: (Richard) 4M background events were generated this weekend out of an attempted 10M. See the post-mortem for a more complete description of problems encountered. Other than pilot error, there appear to be 3 main classes:
incomplete jobs, probably due to run-away propagator
mysteriously killed jobs
bad service from the fileserver
MySQL connection problems, most likely because default configuration only allows 100 concurrent connections. Can we avoid attempting to connect if constants are not needed? [Alex has since upped max connetions to 1000. Connection is only made when/if applications ask for something in the calibration TDS. ed.]
CGI scripting: (Richard) Ray Cowan, who handled CGI scripting for BaBar, believes we ought to be able to operate similarly; that is, designate a responsible person (that would be Alex) for all our CGI scripts. Once we get this formalized, we can start seriously using Navid's stuff. It's already running on Glast01 but it's stuck behind the firewall.
ROOT report: (Ursula) Rene Brun warns Go4 could be prohibitively expensive since it uses QT and suggests using the ROOT (built in) TTreeViewer instead. The cost of licensing QT on Windows in approximately $500 (special rate SLAC online is getting; usual is $1500). Richard believes this is tolerable if the QT license is only needed for Windows developers, not for Windows users. We need to investigate whether or not this is the case.
The tree viewer provides many useful features but we would probably want enhancements. It can be started up either from CINT or from the main ROOT browser, TBrowser.
EM: (Joanne) As of last night, the ebf code can read in FITS-wrapped files as well as raw ebf. It produces equivalent results for our favorite 5-muon-event ebf test file and the FITS-wrapped version.
OPUS: (Dan) He's been playing with resource files and so forth, learning how to configure a pipeline.
IExternal: (Toby, et. al.) Toby made a proposal to address the proliferation of external library interface packages visible to both GlastRelease and ScienceTools people. In the current scheme all are visible whether or not they are needed. He would divide them into three groups: those common to both camps (for which use statements would stay in the IExternal requirements file) and those needed only by one container or the other (use statements would move to that container). See follow-up to the above link for Joanne's counter-proposal, based on a partial misunderstanding of the original, and Traudl's comments. We're probably not done with this topic. We all agreed that the Geant4 interface package, currently the only one with any buildable content, should be split into two packages, one pure interface package to stay in IExternal and a new package, outside IExternal, for the test program.
Workshop and geometry: (Richard, Leon, Joanne) A workshop in preparation for DC 1 (Data Challenge, for the acronym-bemused) will be take place in June or July.
One goal will be geometry validation, which hasn't been looked at for something like 6 months, except that Leon has recently discovered there is a gross error that should have been caught long since: TKR, CAL and the grid are all "too high" by about 3 cm (Z = 0 is approximately at the back face of the grid rather than the front as it should be). It hasn't yet been determined whether the ACD is also displaced by a similar amount. If so, probably no great harm has been done. If not, the incorrect geometry could significantly affect triggers. There are a couple likely sources of the error which Joanne will investigate. We also need better ongoing oversight to avoid any more such long-lived gaffes.
One difficulty in maintaining anything like an up-to-date geometry description has been the lack of coherent information. The last moderately comprehensive (including dimensions of larger components and the gaps between them) document Joanne is aware of is from July of 2001, LAT-DS-38.2. Richard will see if something can be done to remedy this situation.
Move to VC7: (Toby) He proposes that the end of May be the cut off date for VC6 in that
we no longer build VC6 versions of external libraries for distribution
we no longer require new code to build and run properly under VC6.
Gaudi and gcc 3: Richard asked whether anyone has any news on this. No one did. Toby's impression is that Gaudi developers are all too preoccupied to work on this or any other outstanding Gaudi issues. [Subsequently he and others have found evidence to the contrary. There does seem to be a somewhat unofficial version we could try. ed.]
previous | minutes index | next |
J. Bogart Last Modified: 04-Aug-2004 15:39:54 -0700