This is page where you can put your inputs/comments/... For new topics, please start a new item, and for comments to existing items, please add subitems.

Fits for different hypothesis

How to handle fitting the same 'track' as a pion and as an electron? The electron fit may look very much different from the pion one, and may include things like the addition of bremsstrahlung in the trackfit itself (which changes the momentum at some location). This type of change is 'easy' mathematically in a Kalman formalism (it is in principle no different from the effect of energy loss in material). Is a new 'track' made for a different hypothesis? How is the bookkeeping done all the way through to the analysis level, i.e. how is the 'overlap' between the 'electron' and 'pion' versions of the track handled?

This is a good point. We already have such a use case if we decide to refit electron tracks with our current implementation of the electron fit. The trajectory can have larger local changes of curvature and the covariance matrix is larger. In the past we indeed considered the possibility to add photons into the electron track, but was not implemented due to lack of time. In that case we clearly would not only have to create a new protoparticle but also the underlying track changes.

Some simple implementation of this could be to add a flag to the track specifying the particle hypothesis used in the fit; e.g. MIP or electron. In the standard reconstruction tracks are fitted as MIP, in a later stage they can be refitted with other PID hypotheses.

  • SomeOtherPerson (some date) Some clever comment on the above subject goes here...

Is there a need to have a seperate/dedicated class representing trajectories

At this point, there is no seperate class which represents a trajectory, and its functionality is fully 'absorbed' into the track. The open question is whether a seperate object makes sense.

This is a bit of a change with respect to the current model. The track becomes a lighter object and a trajectory object is added. A difference is that in this case a finite geometrical representation of a trajectory exists that can be obtained analytically, i.e. without making use of the transporter. I think if parabola, helixes, lines, etc. A use case could be vertexing. It is still not clear to me whether one would intersect trajectories or tracks with surfaces or track,since in most use cases (apart from vertexing) extrapolation will happen over distences longer then the validity of the trajectory.

  • SomeOtherPerson (some date) Some clever comment on the above subject goes here...

Is there a need to specify algorithm settings in the history?

To me this seems more in the reign of general Gaudi provenance, i.e. how was the executable which did some processing configured...

I think the answer is no, this is indeed a general Gaudi problem. For a given event we must know the version of the program was used, and hence its configuration. It is a property of the event, not of the track. The same applies for conditions data. In fact, I don't really understand the current definition of history, in the current implementation the track type is sufficient because the sequence of algorithms needed to produce that track type is unique for a given program version.

Next Topic goes here...

-- GerhardRaven - 03 Apr 2005

This topic: LHCb > WebHome > LHCbComputing > LHCbTrackModelTaskForce > TrackmodelInputs
Topic revision: r5 - 2005-04-06 - MarcoCattaneo
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback