Linear Collider Forum

Home » Analysis and Reconstruction » Tracking & Vertexing » Fitting scheme
Re: Fitting scheme [message #1987 is a reply to message #1984] Wed, 12 May 2010 04:52 Go to previous messageGo to previous message
Messages: 41
Registered: March 2009
Hi Jason,


I like the idea of a TrackFitterBase. From experience, trying to put all of the functionality in one class can be unwieldy.

However, after that it is more complicated.

Yes, I think one base class is what we actually want and need; to simplify the usage down the road.


As it was pointed out before, there are different methods (and meanings) of the residuals. One has to be careful that the correct routine is called for a fitted track.

Yes, I agree. I'm heavily influenced by the terminology of the DESY group, so I suggest this naming scheme:

residual -- the geometrical distance in x/phi at constant y/r between an associated hit (from track finding) to its fitted track, when it is excluded from the fit
distance -- the geometrical distance in x/phi at constant y/r between an associated hit (from track finding) to its fitted track, when it is included from the fit

The resolution is then the geometric mean of both values. (For reference check e.g. Ralf Dieners thesis or physics/0402054)

So my proposal would be to call the two functions in the TrackFitterBase, including a third one (which is optional, but might be more interesting down the line)
  • calculateDistances(...)
  • calculateResiduals(...)
  • calculateResolution(...)

We would still need some kind of definition or interface to express the alternatives, e.g. perpendicular distances to the track (although this can get pretty ugly).
By doing this in the actual fitter class we would hide the iterative fitting calls (which are needed for the residuals calculation) within this code. I'm not really aware if there are any limitations to the actual fit method. To be more specific, I don't know if the Likelihood method can work like this.


One idea that I had previously was to let the fitting processor be responsible for calculating the residuals.
One advantage to using this method is that the fitter could check the track to see if it was fit using this method, and quit gracefully, if it wasn't. It also allows most of the code to be kept in one place. Note, I am not suggesting that the processor _is_ the fitter, they could still use a sub-class to manage the fitting and residual calculations.

One disadvantage of this method is that I don't think analysis logic should be placed in the fitter. If the residual calculation is done with the fitting processor then it is probably going to be an "all-or-nothing" choice of which tracks to calculate residuals for. This may not be a bad thing - a _real_ analysis processor could just ignore any unneeded information.

I think it is not a good idea to let the processor handle the logic, for several reasons. The extra overhead needed for the determination of the fit method is not large, but somehow confusing. As you mention, several things would get mixed by doing it this way.

The underlying problem is of course something else -- the LCIO objects lack some, eventually fundamental functionality. For example, if it was possible to attach a hit to track, but mark it "unused", then we would have the solution. This would encode all information from the fitting inside the data object. It would also go beyond the scope of fitting.
Probably I will have to take this issue to the LCIO maintainers. In principle this would the solution to a lot of the problems we have there right now.

The next is more like a comment:

Is it common for a objects to be reconstructed with one method and then fit with another?

When analysis is done is it usually done to all of the tracks or just ones which are interesting?

a) what do you mean by "reconstruction method" ?

b) yes and no. You usually have a lot of requirements for tracks (and its components), and you usually only take a fraction of all tracks that passed these requirements into account. (Something like: Chi^2 value, number of hits, position, hit quality, track angle, environmental factors, ...)


When you have eliminated the impossible, whatever remains, however improbable, must be the truth. (Sir A.C. Doyle in Sign of Four)
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic:TPC Tracks not being produced
Next Topic:Conditons Data for MarlinTPC
Goto Forum:

Current Time: Thu Feb 20 22:26:52 Pacific Standard Time 2020
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software