DØ Level 3 Algorithms Meeting:
17th April 2002 in the Farside
Talks, verbal reports
-
Update on tracking geometry for L3:
Robert Illingworth.
Full offline geometry is now available for the tracking detectors.
Daniel Whiteson has checked that using this he gets the same results
as if he uses the standard offline geometry.
-
Using stereo SMT information on
tracks that have only axial CFT:
Daniel Whiteson.
The global tracking has been updated so that axial-only CFT tracks are
matched in r/phi only to SMT, but then stereo and z information in SMT
is then searched for.
Initially, the main motivation for this is to improve the performance
of the track-based primary vertex finder.
Chris Barnes will report on this at next week's meeting.
Daniel also presented some timing information. Using the debug
version on d0mino the time per event with the latest version of the
code is 150 ms.
It look like this will
be fast enough, given that we'll be running the maxopt version on
the L3 farm, whose nodes are 1 GHz Linux cpus.
The unpacker time is thought to be 30, but in which units we weren't clear.
-
Checks of data taken with p11.04
and processed on the offline farm:
Yann Coadou.
-
Yann has found that the L3PhysicsResults are empty on reco output
files produced on the offline farms.
This problem was reported three months ago and a change expected to
fix the problem was made. Obviously it didn't work.
Yann will chase this with the reco experts.
The fact that it took us three months to notice, clearly reminds us (the
L3 algorithms group as a whole) that
our monitoring leaves much to be desired.
-
Yann has found a new potential pitfall in running tsim_l3.
He tried to use a level3.sim file that happened to have been created
when the calorimeter was out of the run. In this case, the crate list
in the level3.sim file doesn't have calorimeter, which means that no
calorimeter data was unpacked.
Short term solutions:
-
1) Use a
level3.sim file that is created during a normal global run.
-
2) Just remove the crate
lists from the .sim file completely; the L3Runconfig tool will then
use the default initialisation, which will work fine.
Medium term solution: Now that the muon and tracking unpackers are
"dynamic" the only detector that needs the crate list facility in the
.sim file is the calorimeter. Since this is anyway very stable
perhaps we should dispense with this option or at least have a flag
that can turn it off.
-
d0_analyze issues: (some of which comes from Yann's discussions with
Dugan after the meeting):
-
event_info is now included in the executable and
will be in the default rcp of d0_analyze in p11.05.
-
It is not understood why D0Analyze_x is present in some releases, but
missing in most of them. Dugan will take this up with the release managers.
-
Getting d0_analyze running on the offline farm. We need to supply the
list of tool names that have been active in a particular run.
Our ideal solution would be for an automatic procedure to run on the farm:
-
Query runs database to get trigger name.
-
Query trigger database to extract relevant tool names and write a file
containing this info.
We should push for database manpower to be provided to do this.
Some debate about whether or not we should in the meantime provide
a fixed file containing the tools we are currently running.
-
Analysis of test runs for L3Muon online: Christophe Clement/Martijn Mulders.
-
Christophe will complete work on the new unpacker by bringing together
all the material he has presented in a Technical Note.
-
Timing per event (ms) for p11.04.01 (maxopt) on a 1 GHz clued0 node:
-
Unpacker. <2
-
Local muon tracker (default rcp). 70
-
Local muon tracker (+ Christophe's L3 tune of number of iterations and
step size). 40
-
Local muon tracker (+ Martijn's tune of numbers of allowed segments). 25
-
Running full trigger list on a global_CalMuon dataset. 420
This is an overestimate: it needs repeating with the L1
trigger bits used to decide which L3
filters to run on each event.
-
Number of single muon triggers with at least one loose L3 muon goes
down by 1-2% with Martijn's tune of numbers of allowed segments.
This is probably a resonable estimate of the resulting loss in
efficiency, but it would nice to check this fraction on the sub-sample
of the events that have a tight offline muon?
Discussion
-
How should we input to script-runner the various pieces of steering
info that may vary run to run? These vary from very important pieces
of information that need to be tracked: such as which geometry files
should be used, to things that really don't affect performance at all
and are just "administrative" details, such as which online machine
the monitor data should be sent to.
RCP is a bad place - change requires a new code release.
Trigger list is where we currently do this, but this is not really
appropriate either. Perhaps we should have (another) flat file that
would be logged in the runs database?
-
Other people are re-discovering our Mark&Pass bug in p11.01.00 data.
The
L3 bugs page
has been updated with information provided by Yann.
We should advertize this information more widely.
-
L3 preparations for trigger workshop on 22nd-23rd April: We should
use this opportunity to expose to the wider D0 audience our wilder
ideas, things that we think may be controversial, appeals for extra
help, worries, etc.
Terry Wyatt will send around by email his list, but input is solicited
from everyone on this.
Please let Dan and Terry know if you expect to present something.
Scribe: Terry Wyatt.