Core Minutes 3/27/2012

• ScienceTools: (Jim) fixed a bug having to do with writing out counts spectrum, added enhancement to make it easier to turn energy dispersion handling on and off, and changed test condition used in gtmktime to account for new values of data quality flag. See Science Tools Development Notes for details.

• FSSC: (Tom S.) FSSC is doing the peer review of the recent cycle of proposals.

• Data crawler: (Tom G.) There has been a spate of crashes recently — over the last couple days at least, perhaps over the last week. Tony J. found a malformed ROOT file which may be at fault. However, it doesn't explain similar problems seen earlier since it's a newish file. (Heather) will look into the general problem of bad ROOT file handling.

• MySQL migration: (Heather) No real change from last week: everything is ready to go except for OpsLog because the responsible person (Tony J) has been out of town and unable to test it. We considered moving just the databases intended for mysql-node03 but will hold off because the MySQL server there is due to be upgraded soon from MySQL 5.0 to MySQL 5.5. We should check that the databases already resident on that machine (includes at least SCons RM) are compatible with 5.5. Given our experience with testing on mysql-node01 we should at least check for possible use of new reserved words.

• Pass7 news: (Leon) As Tracy predicted, I found at least one of the memory leaks in my job that produces the software-truncated digis, all by myself. The fix got rid of about 3/4 of the problem. The remaining leaks seem to have to do with xerces and things like DOM along with some remaining SiStripList issues. I'm trying to figure out whether they're just 1-time overhead, or something ongoing. I would naively think there shouldn't be any memory growth in the job that I'm running.

  Elliott asked for a way to turn off ghost tracker hits in pass7. I realized that my methods that filter ghost hits (and normal hits, for that matter) never made it into v17, but I don't see any harm in adding them, since they don't do anything if not activated. There's a new GR v17r35p24gh01 that incorporates this mod. I guess we can process a short run with the Level1 GR and this new one, and if they agree, we can make the case for porting this over to the mainline v17 at some point. (Heather) We should verify it doesn't disturb anything with systests.

  (Leon)Otherwise, I hope to get back to debugging the software-truncation version of the code, which currently crashes on linux. I'm pretty sure it has to do with null pointers, and probably came about when I re-arranged the gaudi sequence. (That is, it exposed unprotected code.)

• Pass8 news: (Heather) There is a new HEAD incorporating Phillipe's memory leak fix. (Tracy) is hopeful this will address the crashes.

• L1: (Heather) has finished all the code changes needed for L1 + new Gaudi. It works, just needs to be tagged.

  Purpose and meaning of the branches off the L1 code — about 5 at last count — will be documented soon in the GlastRelease Updates Confluence page.

• Core talk:

  • Systests (Heather) Liz ran Systests on a SCons-built L1 release. We should also do it for Pass8 and compare to results for a CMT build.

  • Installer and GR This wasn't mentioned at the meeting but maybe should have been. Short summary: Tom S. has fixed the problem. GR releases are now available from the Installer.

  • New SCons version (Joanne) tested 2.1.0 on Linux. It seems fine there as well as on Windows. There are probably some minor improvements (performance improvements, bug fixes) relative to 1.3.0, mostly affecting only Windows and no known problems in upgrading. RM can start using it immediately on Linux just by pointing to the newer version. It will become the default for users on SLAC Linux as soon as some sym links are updated. It needs to be installed on glast-win04 before RM can use it there. (Heather) She or Tom will take care of the installation.

  • GR vc90 (Joanne) Heather has made a new CLHEP debug build which is properly formed (commpiler and linker build our code against it happily; debugger likes it) and also a new G4 build which depends on it. However, the crash in the TkrRecon test program has not gone away. It occurs when an object of type TkrCovMatrix (defined in TkrUtil) is instantiated. TkrCovMatrix inherits from CLHEP::HepMatrix (which in turn inherits from CLHEP::HepGenMatrix) and also from the pure interface class Event::ITkrTrackParamsAccess. It appears there is a problem with setting up the virtual function table for the latter class, at least I think that's what's happening in the bits of assembler generated by the compiler and not corresponding in any obvious way to the C++ source code.

previous

minutes index

next

J. Bogart, Last Modified: