Minutes of the tracking Review held on March 24th, 2000
Present: G.Corti, G.Gracia, M.Cattaneo, P.Mato, R.Hierck , R. Van der
Eijk, M. Needham, R, Forty,
N. Neufeld, D. Liko, M. Frank
Minutes : G. Gracia
The tracking software in Gaudi was presented by Matthew Needham
The current implementation of the track fit in
Gaudi was presented by Matthew Needham. He also
introduced the general framework they have in mind to include the different steps from
pattern to the final
track fit. They foresee to go several times trough the following cycle:
track seeding => track following => track fitting
The first time starting in the field free region (stations 7 to 10), the second starting
in the vertex....
The different passes are controlled by a sequence of top algorithms.
In the current implementation several
algorithms are called sequentially: LayersofHitsCreator,
TracksCreator, FitInitializer, TracksFitter. Data produced by any of these
algorithms are stored in the
data stored and read from there by the following algorithm in the list.
Currently the TracksCreator and the FitInitializer
take care of cheating the pattern recognition.
The TrackCreators output is a list of hits assigned to each track. The fit
initializer provides a first estimate
of the track parameters. RF mentioned that these two algorithms will converge into the
pattern recognition
which will produce a set of hits together with a first estimation of the track parameters.
PM recommended to
merge these two algorithms now, as they will be just one pattern recognition in the
future, so the general
structure of the program will not change when the pattern recognition is ready.
Interaction with RICH
There was some discussion about the communication
between subdetectors. In particular between tracking
and RICH. The track fit algorithm will produce a list of tracks which will be used by the
RICH algorithms. The
rich output has to be included in each track as a pointer to a particle Id object produced
by the RICH. One
proposal was to have a pointer to a particle Id object in the tracks produced by the
tracking algorithm. This
pointer is only filled when the RICH algorithms have produced the associated particle
identification for the
tracks. That solution somehow violates the general rule that the objects on the store
should not be modified.
However in this case it is maybe harmless to update simply this pointer on a track.
Another approach would
be to write a new track container with particle Id after the RICH. The first approach
seemed to be preferred by
most of the people. However, problems can occur if, for instance, the tracking code
deletes tracks being pointed
to by the RICH pattern recognition as that would result on an undefined pointe, to delete
items in the store should
not be allowed.
As a general conclusion of this discussion is that communication
between subdetectors has to be encouraged to
agree about the overlapping parts of the software or the data they share (Topic for the
software week? )
I(O)THit classes
There was a long discussion about the meaning
and functions of the ITHit and OTHit classes. Currently
they are simple objects which keep references to the corresponding I(O)TDgi and the
I(O)DetectorCell.
I(O)Hit can answer questions like distance to wire, error on that distance or
predicted distance to wire. To
answer the first two questions, as the answer depends on the possition along the wire, the
position of the
track extrapolation should be provided. The argument needed to answer the third question
is a track state. To
extract the distance to wire the OTDigi needs the R-T relations from the ODetectorCell
and the drift time
from the OTDigi. One important different between OTHit and ITHit is
that ITHit are (will be) clusters having
more than one reference to ITDigit. There will be more ??Hit (VeloHit, MuonHit) in
the future.
PM stressed the fact that creating a detectionCell
object for each hit might result on a huge overhead.
Some of the questions the detector cell can answer might be formulated to the layer where
the cell is (stereo
angle...). Some others may depend on the wire number and even the possition along
the wire (R-T relations for
chambers in the magnet) but these questions may probably be asked to the layer with some
argument like the
wire number or the position in the layer. The current detectionCell implementation
was needed as there was
no geometry description in Gaudi when this work started and the geometry had to be
extracted from the cdf
files. It was agreed that this particular points requires some more thinking in the
future.
Access to MC truth.
In the present implementation of the
tracking MC hits inherit from the Hits (ITMCHit from ITHit,
ITMCDigi from ITDigi and the same structure for OT). The fit uses on I(O)THit
and the dynamic
down cast is encapsulated in monitor objects used to test the fit. To be sure the
fit works with ?THit
and not only with the MC hits MF proposed to encapsulate the creation of the
hits, in other words the new,
in a factory method which could create MC, or real hits when requested to do so. To
be sure there is
not hidden dependency on the MC truth in the algorithms one can easily run with real
hits.
The access from reconstructed tracks to MC true
tracks is a different, more complex, problem as
the relation will not be to one as soon as there pattern recognition is ready. The Gaudi
team has foreseen
the use of Associators to get this kind of relationships. The Associators
will encapsulate the navigation
to the MC information. For a given contained object it will return a reference to another
MC contained
object. The complexity of this Associators can vary a lot. For the tracks they can
be clever to request
more that 90% of the hits in common, or more than 80% but a different between the
reconstructed and
the true track parameters smaller than a number. Gloria will try to produce the basic
structure for
the associators for the next Gaudi release. An associator will implement the IProperty and
IAssociator
interfaces. They can be configured using in job options if one wants to use some
parameters internally in
the associator.
Generic, user triggered, track propagator
The tracking group currently does not provide a
general way to extrapolated a give track to any
possible Z position. To be able to do that one may have to store a huge amount of data in
every hit in
the track. Otherwise one would have to repeat the track following consuming lot of CPU.
Currently
track states are stored at a given number of Z positions specified in the job
options (that was already
done in SICB). A generic propagator is needed , even if it is very expensive in terms of
CPU it will be
used for certain applications (Ks fitting)
Geometry description
The tracking group expressed their concerns about the
existence of two detector descriptions for
simulation and reconstruction in the near future.
An automatic tool to convert cdf files to XML
files is not possible as much of the knowledge about the
detector geometry is in the SICB code. The possibility to write a tool to produce XML from
the GEANT3
structure can be investigated. The XML code produced by such tool would be completely
unreadable
(detector component names produced automatically cannot be meaningful).
Also the possibility to have another tool to
convert XML into CDF was mentioned as a possible
cross-check.
This is a general concern in most subdetectors and
the computing group and will be addressed in the
software week.
Serialization of objects. Unhomogeneous containers in the data store
The tracking software uses containers of a
base class TrTrack which can be inner or outer tracks.
This gave some troubles in Gaudi which will be solved (MF) in the next release.
Tools
The tracking software uses different instances of
some defined algorithms in many different. They
would prefer to have some global tool which they could use all over their software.
The Gaudi
team plans to provide some machinery to use tools from the algorithms. These tools will do
specific tasks for the algorithms without using the data store. Data will be passed
to/from the tools
as arguments. These tools will also be configurable via the job options. It is not clear
these tools
is what the tracking group had in mind: Personal discussions would be useful to clarify
this point.
Troubles due to the separation of data and algorithm
A concrete example was provided by the tracking
group: They would like to be able to reorder
the clusters as a function of a given quality factor. They cannot reorder the hits in the
data store.
(that would be a disater if some other algorithm keeps references to those hits). The
solution
proposed is to create a local container of pointers to the hits in the store and the
quality factor and
order them locally.
AOB
PM asked if the tracking group has studied the
tracking software of other experiments as it could be
very useful. CMS claims they can reuse their inner tracking algorithm for their muon
detector with very little
changes. There could also be some kalman related utilities in future versions of CLHEP.
The LHCb track fitting code is very similar to that of
HERA-B and was also used in outer tracker
test beams with few changes.
The tracking software is somehow polluted in several
places by the dependencies on SICB. It was
clear from the discussion that the influence of the legacy code in the new program should
be minimized.
Plans for the future: To put the existing code in the
repository requires some changes. They use
a private dataObject because of the serialization problems. They asked for guidelines on
how to book
class or histograms Id's. For the histograms it was agreed to have separated directories
in hbook so
the subdetector have freedom to choose the numbers in their area. A solution for the class
id asignment
will be provided very soon.