p16 certification

The grand plan is to have a set of plots to be used a reference plots so we can monitor the performance of the tools. So far all you get is links to talks that mention L3 Muons.

L3 Meeting 03-02-04

L3 Meeting 17-02-04

Here is the write-up: D0 Note 4470

p16 certification -- bits and pieces:

TrigSim leaks a large amount of memory. Try to stick to jobs with less than 1000 events.
To speed things up and to reduce memory consumption do 'addpkg d0trigsim' and edit the appropiate framework rcp for running TrigSim (the names are pretty obvious) and remove anything mentioning tmb (3 rcps) as you only want the DSTs. Then run with the -localfwkrcp option. That way you should be able to run over at least 2000 events in one go.
TrigSimAnalyze tends to crash. The bug is rather subtle and not easy to reproduce. When running TrigSimAnalyze reduce your tool list file to the bare minimum:
L3ErrHandle L3ERR_offline_info
L3RunConfigMgr RUN_CFG
L3GeometryManagement GEO
L3TMuoUnpack MUOUNPACK_DEFAULT
L3TMuoLocal MUO_LOCAL
L3TMuon Muon
is all you need when looking at muons.
Then run with the -l3toollist=trigsim/mytoollist.txt option. Most of the time this will do the trick and TrigSimAnalyze will not crash. If it does please look at the core file if you see something obvious.
Due to the fact that HepTuple/root can only deal with variable names up to a certain length, all names will change in the higher p15 releases to avoid mysterious crashes. If you get a core dump when running TrigAnalyze and the debugger produces an output like this:
#9 0x42290080 in TLeafF::TLeafF(char const*, char const*) () from /D0/ups/root/Linux-2-4/v3_05_04bGCC_3_1-exception-opt-thread/lib/libTree.so
#10 0x085fff02 in HepBranch (this=0xca865f0, name=0x435dc9d4
MUO_CENTRAL_MATCH_d_off, address=0xca9475c, leaflist=0xca95a34
MUO_CENTRAL_MATCH_d_off_NCentralMatch/I:MUO_CENTRAL_MATCH_d_off_CMcentraltrack_dca
[MUO_CENTRAL_MATCH_d_off_NCentralMatch]/F:MUO_CENTRAL_MATCH_d_off_CMcentraltr
at /D0/dist/packages/HepTuple/R-03-05-15/root/HepRootNtuple.cc:185
then your variable names are too long.)
If you read in a file that contains events from lots of different runs and therefore tends to read in different versions of the geometry every so often, it tends to crash after a while ('INT4', 'too many ocjects defined' or so). It's a memory problem. I don't know of any official solution, but Slava has provided a fix that will work in p14 and p15 (and maybe elsewhere, I haven't tried). Read about it here.

Daniela Bauer

Last modified: Wed May 19 09:48:10 CDT 2004