DØ Level 3
Algorithms Meeting: 24th July 2002 in the Farside
Talks
-
Comparison of track-based and hit-based primary vertexing in z:
Chris Barnes.
Chris compared the performance of the p12 version of the track-based
primary vertexing in z with that of the hit based vertexer.
The bottom line appears to be that the track-based vertexer has substantially
higher efficiency and purity for all the classes of events studied.
Discussion:
-
Could we run the hit based algortithm on events where the track based
algorithm fails to find a vertex?
-
What are the prospects of extending tracking into the "overlap" and
forward regions? We would need to investigate new tracking algortihms
(e.g., histogramming) in order to get tracking coverage extended.
-
Technical issues and tau studies: Yann Coadou
-
Using the new facility to make comparisons of on- and off-line results
in l3fanalyze, Yann finds discrepancies in, e.g., E_tau, of order
10^-5 level. (This is rather less significant than his comparisons on
older data done some months ago. Will be followed up.)
-
l3muon crashed in p11.10. Thought to be due to a fix that was not
propagated to the test release (again)! Also, p11.10 changes for muon
reco went in without Martijn being alerted and therefore without
explicit checking/approval by L3 muon group. This is contrarary
to our agreement with the offline muon guys.
Action item: Martijn will make sure this doesn't happen again.
-
Running L3 tracking on MC or data "is a pain".
Action item:
In the short term we need documentation on the steps necessary to get
correct L3 tracking results on MC and data so that idiots can use it.
Daniel Whiteson will provide this.
Action item:
Actually, we need web pages that describe the 10 most frequently made
trivial mistakes that catch people out when trying to run L3 trigsim.
PLEASE send Terry Wyatt items and he will put them together.
Just a one-liner to point out a problem would be better than nothing,
but a more detailed explanation of how to avoid it would be very much
more useful!
(In the longer term we need more and more of this technical trivia,
which causes endless grief even for experts at the moment, to be
handled automatically (d0tools, runtime environment, etc).
-
Tau studies: Plots showing a large number of tracks with no
stereo information were inconsistent with Daniel's results. After
meeting this was shown to be due to somehow incorrect running of the simulator.
The conclusion we came to in the meeting of the need for a p12 code
change to allow phi-only matching in the tau tool is suspended,
pending further investigation.
-
Some new Monte Carlo files with p11.09 d0sim are now available that
include simulation of calorimeter non-linearity and more realistic
simulation of noise. Comparisons with old MC and data have just started.
Discussion Items
-
Terry Wyatt and Elizabeth Gallas have been putting together the new
trigger list, including standalone L3 tracking filters. This means
that L3 tracks need to be promoted to be physics objects rather than
data objects, so that they get stored as physics results. Some
discussion ensued about how best to achieve this technically.
Action item:
Daniel to discuss this further with Jon and then either to implement a
physics tool wrapper around the currently existing tracking tool or to
convert the global tracking tool to be a physics tool and ensure the
tracks are stored.
-
The dip in the phi distribution of L3 tracks seen in the
vertex examine program will be investigated by Michiel Sanders.
Information from Mike Hildreth obtained after the meeting is that
there has been no change to the cft hit maps in over a month (and even
those affected only stereo, which are not relevant to the problem).
-
L3 thumbnail:
Peter Tamburello has volunteered to design and implement the L3 part
of the thumbnail. He has started to ask us a lot of awkward
questions! For example:
-
The previous official design calls for typically 4 or 5 16-bit words for
each L3 physics object.
This is almost certainly grossly inadequate for detailed technical
studies and precise (per mille level) estimates of trigger
efficiencies.
For example, consider electron candidates; they have E, eta, phi,
emfrac, three transverse shower shape measurements, track match
information (track id?, p_t, match chi_squared), preshower match
information.
We need to think carefully about whether or not we need all this
information on the thumbnail, how much precision is needed and how
efficiently it can be packed.
-
Should people doing detailed technical
studies and precise estimates of trigger
efficiencies be expecting to use DST rather than thumbnail?
(This would be particularly bad for those of us working outside Fermilab.)
-
Items that came up in the discussion that have a wider relevance than
just the thumbnail:
-
One particular feature of the current electron filtering is that we
define new instances of the electron tool to correspond to different
cuts on emfrac, shower shape, track match, etc. Although there is
some motivation to do it this way it looks like it would be better to have
only one electron tool which calculates all the relevant quantities,
which are then cut on in the filter.
In this way we would avoid unnecessary duplication of L3 physics_objects
corresponding to the same electron.
-
How do we most efficiently associate physics objects in the data structure,
e.g., central tracks to lepton candidates?
-
How do we most efficiently associate filters and scripts that are
satisfied to the physics objects that caused them to be satisfied?
Do we need filter_results objects?
In addition to thinking about these difficult questions, Peter will
start to implement the basic framework and store the bare minimum
information for each physics object.
ACTION ITEM FOR ALL TOOL AUTHORS:
HE NEEDS YOUR DOCUMENTATION OF THE L3 PHYSICS OBJECTS NOW !!!
Scribe: Terry Wyatt.