Home » PANDA » PandaRoot » Bugs, Fixes, Releases » PID package
| Re: PID package [message #9179 is a reply to message #9143] |
Tue, 11 August 2009 13:03   |
Jens Sören Lange
Messages: 193
Registered: June 2005
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Dear Bertram et al,
I would like to add a few more notes, because I think that it is an important and interesting discussion,
and I have a different opinion about some of the issues which you raised.
1.) The "set methods".
They are by intention.
It was one of the PandaRoot principles from the beginning.
It is intended to be a protection mechanism, that one class is not
able to simply overwrite data members in a another class
(example "the pT of my track is negative, which package did that?")
Or, in other words, the avoid "global variables".
2.) It seems you would like to strictly separate
the reco part (track fitting) on one side
and the PID part (e.g. track extrapolation) on the other side
(and then assign PID into analysis instead of reco).
And your point seems to be (please correct me, if I'm wrong),
that you think that Stefano's approach (i.e. the track extrapolation
and filling PID information directly after the track fitting,
i.e. in the reco part) is in your opinion not a good approach.
So, what you have in mind, is
a.) tracks as reco objects
and
b.) tracks as PID (in analysis) objects,
and in most cases they are probably the same.
Now you are proposing to work with references to the track objects.
However, what then?
-> do you want to modify the tracks then in the PID part?
or, in other words, overwrite the tracks?
If yes, I would strongly vote for "hard copying" all the tracks.
Sure, as you say, these are a lot of data and that was actually
my counter argument when you brought up your proposal
(of the separation of reco and PID)
on the tracking hands-on meeting at GSI in March 09.
It is not only the py,py,pz, but vertex, covariance matrix, etc. etc.
But I really think it would be safer to copy the tracks,
and not overwrite.
That is why I think that Stefano's approach
is quite nice (filling the TCandicates _before_ you copy)
3.) Coming back to the point of probably overwriting tracks.
The question would be, why.
It seems that you would like to do a track fitter refit
in the PID part (i.e. then at a quite late stage in analysis).
But we decided on the PID Mini-Workshop at GSI in Sep 2007 that
track fitting will be done for 5 different masses (pi,k,p,e,mu)
anyhow.
That's also the Belle approach, and it was a majority vote to use
this as PandaRoot PID approach at that workshop.
That's even at a step before the PID.
The PID then tries to make a decision, which particle it was,
but using the momentum from the (already before finished) track fitting.
Probabilities (e.g. the probability that THIS track is a pion)
should then be calculated using the momentum from the track fitted
with THAT pion mass hypothesis.
What you probably have in mind (if I understand correctly),
is improving the PID decision by improving the track fitting,
but very late in the reco sequence, after track fitting
has already been performed, using some new information (from PID).
a.) But which new information could improve the fit?
(my point is: maybe I cannot see exactly the need for another
track refit in PID). Track Refit is important after final alignment
and/or IP vertex information from database etc. etc.
but is it really useful after calculating the PID probabilities?
Even dE/dx (which could enter the fit as a weight for hits)
is already fixed and known before the PID part.
b.) I would also vote for avoiding a (sort of) "hidden" (re-)track fitting
in the PID part. (or, in other words, I would think that a track fitting
should only be done in the tracking part, i.e. in reco).
4.) a re-fit is still possible for the TCandidates.
That's for example the vertex constraint fit or the mass constraint fit
as Klaus and Dipak implemented it anyhow (shown e.g. in
the Torino tutorial).
cheers, Soeren
|
|
|
|
Current Time: Fri Apr 26 15:07:03 CEST 2024
Total time taken to generate the page: 0.00995 seconds
|
GSI Forum
Search
Help
Members
Login
Home
