Home » PANDA » PandaRoot » Tracking » Strategy discussion on Track objects
| Strategy discussion on Track objects [message #8341] |
Wed, 29 April 2009 14:05  |
Ralf Kliemt
Messages: 507
Registered: May 2007
Location: GSI, Darmstadt
|
first-grade participant |
From: *to.infn.it
|
|
Hello everyone,
Currently we have several track objects:
| Quote: |
genfit: Track, TrackCand
pnddata: PndTrack, PndTrackCand
lhetrack: PndTpcLheCMTrack (monte carlo track?), PndTpcLheTrack, PndLhePidTrack
riemannfit: PndRiemannTrack, PndTpcRiemannTrack
trackbase: FairTrackPar
stt: PndSttTrack
gem: PndGemTrack
dch: PndDchTrack
fsim: PndFsmTrack
tpc: PndTpcClusterTrack
|
Now the question is how we can proceed.
My first suggestion on this is to get rid of the detector specific objects by using only PndTrack and PndTrackCand. Be reminded to make use of the detector numbering definitoins in pnddata/PndDetectorList.h.
The second point is more complex and is regarded to the unification of the track objects used by the finders and fitters in general. A point which was made is that a track object should be able to provide a propagation functionality. This however conflicts with the policy to have data classes only storing their data, as far as I think.
I would be glad to have some comments by the different experts on this. When it is needed to discuss this more directly I'll set up an evo meeting.
Kind regards, Ralf.
|
|
|
|
|
|
| Re: Strategy discussion on Track objects [message #8344 is a reply to message #8343] |
Wed, 29 April 2009 15:24  |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
I think, another important point is how to correlate the information from the prefit track (in my case, PndTpcLheTrack), the fitted track (genfit track), the track containing the pid information (PndLhePidtrack), and the PndMicroCandidate.
In my case, from the prefit track PndTpcLheTrack I create the pid track, and the kalman track. But there is no relation between the Track and the PndLheTrack. What should one use to fill the MicroCandidate?
I mean, it should be important, I think, to design how these classes should cooperate. At the moment I have no clear ideas, comments are welcome.
|
|
|
|
|
|
|
|
| Re: Strategy discussion on Track objects [message #8356 is a reply to message #8349] |
Thu, 30 April 2009 13:43 |
Bertram Kopf
Messages: 110
Registered: March 2006
|
continuous participant |
From: *ep1.ruhr-uni-bochum.de
|
|
Hi,
you are discussing here typical software design issues. In my point of view it would be helpful to firstly work out a -more or less- proper design, followed by dummy implementations before one then starts with concrete implementations of alorithms etc.
In this discussion 3 different things are mixed-up:
1. tracking of charged particles,
2. PID and
3. the interface to the analysis (PndMicroWriter)
Here are just few remarks to these 3 points:
1. Tracking: Ralph is completely right that only one common track object should be used. The important thing is to think about how such an object should look like, what features shoult it have, if there is the necessity of abstraction, etc..
2. PID: PID has in priciple nothing to do with tracking of charged particles. It should also be possible to do PID for neutral particles: e.g. gammas, neutrons, merged pi0's, electromagnetic split-offs etc. I think, it is therefore better to decouple it from the tracking and to provide only PID specific software parts. Of course, the relevant objects should have an assoiciation to the corresponding tracks or EMC clusters.
3. The interface to the analysis should not be based on the tracks. The reconstruction should finally provide lists of particle candidates (neutrals, charged, etc.) which are then
the input for the analysis. For sure, these candidates should also provide references to the corresponding tracks or clusters including covariance matrices etc. so that also these informations are easily accessible in the analysis part. Therefore one should think about how such a candidate (RhoCandidate ?) should look like.
Best regards,
Bertram.
|
|
|
|
| Re: Strategy discussion on Track objects [message #8357 is a reply to message #8356] |
Thu, 30 April 2009 13:54 |
|
Anonymous Poster
|
|
From: *natpool.mwn.de
|
|
Hi,
I think Bertram is right about the separation of tracks and PID info.
You say that one should define what is needed from the track object. This is very true. If there are requirements to the tracks which are currently not fulfilled by the genfit Track, we will try to add them. However, since we are using genfit for charged particle tracking, I think this is the way it should go. To make another track object, that will need to learn extrapolation capabilities in a similar way to genfit again, does not make sense.
So, again, if there is any additional features of the track which are needed, we will accommodate them (if possible of course) in genfit. But I also understand that there has been concern in the past that PANDAroot shall not depend on genfit. But as this is the only charged track reconstruction we have and we will have in the near future, there is also no way around it. I do not know how to resolve this contradiction.
Cheers, Christian
|
|
|
|
| Re: Strategy discussion on Track objects [message #8365 is a reply to message #8357] |
Thu, 30 April 2009 23:10 |
Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Hi,
I think almost all of us agree about having a well defined interfaces and cleaning the implementation for the Tracks, PID, etc. We already discuss this in the last collaboration meeting and even start doing something about it! What I do not understand is the statement:
But I also understand that there has been concern in the past that PANDAroot shall not depend on genfit.
In fact it was you (Christian and Sebastian) who wanted to have Genfit separated from the whole Pandaroot from the beginning with the argument "PANDA experiment changed the framework twice and if this happened again GenFit should not be changed!"
In fact Track, PID, etc. belongs normally to the PndData package, which then can be used by all detectors and/or packages, and what Christian suggest is simply all detector and analysis packages should be dependent on GenFit instead of PndData! What would be the problem if GenFit uses PndData? Do you really still believe that PANDA will through every thing in PandaRoot away and keep GenFit?
Maybe we have to clarify very soon the situation with this GenFit, and if you really think it is so general and independent may be you should distribute it as a stand alone package and we shift it to the external packages, or if it is a Panda software which is integrated inside panda software then it has to follow the rules as all other packages.
regards
Mohammad
|
|
|
|
| Re: Strategy discussion on Track objects [message #8367 is a reply to message #8365] |
Fri, 01 May 2009 01:33 |
|
Anonymous Poster
|
|
From: *pool.einsundeins.de
|
|
Hi,
it is very clear also to me that we need clearly defined interfaces and classes. I guess this is why Ralph started this discussion. So, I thought the interface of a useful track object is not yet available. If it were, we wouldnt be discussing it, or maybe there is a misunderstanding after all. So could you try to make clear what your suggestion is please. As I said, I will accommodate what is necessary in genfit. If it is the wish of our community that the genfit track objects can somehow be converted in general PandaROOT classes, we can do that.
The central point of the discussion is to my mind, whether the central track object needs track extrapolation capabilities or not. Could you please give your opinions on that?
I do not understand why you want to move genfit out of PandaROOT. Apparently there is a feeling that we are somehow not respecting some rules (quote from your mail). What exactly is that we are doing wrong? What are your suggestions to improve the situation?
And please excuse me for being mildly frustrated about the code development in the past in PANDA. It just isnt so nice to work many years on some software and then having to redevelop it in another framework. Of course I want to avoid this from happening again. I am glad for you that you are 100% sure about the future of PANDA computing. But please allow me to not share this feeling completely. The past has taught me to be a bit careful about this.
But I want to stress again that if there are wishes by this community that the genfit track object shall be convertible into some common class that we will do that. Just tell us what you need. However, we can not discuss to change the structure of the genfit track object, because the whole design of genfit is based on it.
From reading your email I certainly feel that there is some hostility in the air. It is a pity that this is the case. I think we are in a good situation. We have in PANDAroot a full working charged track reconstruction. This something that we for example never had for all of PANDA in the old framework. This is a great step forward. And just the question of a data interface shouldnt split our community. We all have a common interest. And having track reconstruction is a part of the goal we all want to reach.
Cheers, Christian
|
|
|
|
| Re: Strategy discussion on Track objects [message #8379 is a reply to message #8367] |
Fri, 01 May 2009 16:01 |
Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen
|
first-grade participant |
From: *KVI.nl
|
|
Dear all,
Let's try not to get too excited on these issues and let's try to avoid to revive old struggles and fights we had in the past. Important is that we on a very short term come with a scenario which is used and usable by us all. As Christian already said, we all have the same interest: a workable track reconstruction in our framework. So lets get back to the real issue, namely the point which Ralf stated earlier:
| Quote: |
The second point is more complex and is regarded to the unification of the track objects used by the finders and fitters in general. A point which was made is that a track object should be able to provide a propagation functionality. This however conflicts with the policy to have data classes only storing their data, as far as I think.
|
I have to admit that partly this is a religious issue. So let me be nasty and refer to the computing model which states that one should try hard to minimize the number of internal dependencies. Furthermore, as a personal preference, I would like to avoid to be in a situation in which I need to load hundreds of libraries or find/include the two hundred corresponding header files in order to be able to look or perform a simple analysis on a root-file generated by a pandaroot. I, therefore, believe (!) one should try to separate as much as possible data classes from "functionality" issues, to keep it transparent at the end of the day. Ok, I have to admit, that I am also grown up with this tradition. So, if the majority of the tracking group has a different opinion, I wouldn't have any problem, though.
Kind wishes,
Johan.
|
|
|
|
| Re: Strategy discussion on Track objects [message #8380 is a reply to message #8356] |
Fri, 01 May 2009 16:36 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *8-87-r.retail.telecomitalia.it
|
|
Few comments from my side:
| Bertram Kopf wrote |
Hi,
you are discussing here typical software design issues. In my point of view it would be helpful to firstly work out a -more or less- proper design, followed by dummy implementations before one then starts with concrete implementations of alorithms etc.
|
Indeed I am asking opinion about software design. The code and the algorythm is already implemented, working and tested with my personal design, wich is similar to what is used in HADES and CBM (if I have understood well): track (from tracking detectors) -> pidtrack (the object which stores all the informations for pid, the track + emc eloss, tof, etc.) -> microcandidate (the starting point for analysis). The selectors should be set somewhere, between pidtrack and micro candidate (which at the moment are almost similar) or after microcandidate.
I am just asking if there are ideas on how to have something better.
| Bertram Kopf wrote |
1. Tracking: Ralph is completely right that only one common track object should be used. The important thing is to think about how such an object should look like, what features shoult it have, if there is the necessity of abstraction, etc..
|
The object was designed some time ago, and now it exists also in the code: PndTrack (and PndTrackCand). One should just start to move the old objects to this new track class.
| Bertram Kopf wrote |
2. PID: PID has in priciple nothing to do with tracking of charged particles. It should also be possible to do PID for neutral particles: e.g. gammas, neutrons, merged pi0's, electromagnetic split-offs etc. I think, it is therefore better to decouple it from the tracking and to provide only PID specific software parts. Of course, the relevant objects should have an assoiciation to the corresponding tracks or EMC clusters.
|
I do not understand this point. Of course PID is different from tracking, but you can perform PID only if you have tracks. The PID object has momentum, and you ahve to use momentum + the other variables (such as emc eloss) to distinguish between particle. And only if you have tracks you can understand if one emc cluster comes from a photon or from a charged track. The, I would formulate this sentence as: PID depends on tracking. Or have I missed something?
And the track matching with pid detectors, which is a very important part of pid task, depends on track parameters. Even for the photon ID. The fact that the pid matching is done inside one directory called "lhetrack" is due to the fact that at the moment the algorythm is based on the LheTrack and not on the common PndTrack written one month ago.
The fact that genfit provides a track which will never be a base PndTrack (if I have understood well), complicates the history, because in this case the abstract class cannot be used. But I have an idea.
It could be possible to write a task, inside PndTools, which loops inside Track TCA, and creates a new TCA with PndTrack.This will be the standard track for correlation to PID detectors.
Of course the algorythm could be moved in a new pid package, once it will be uncorrelated to "local" lhetracks.
| Bertram Kopf wrote |
3. The interface to the analysis should not be based on the tracks. The reconstruction should finally provide lists of particle candidates (neutrals, charged, etc.) which are then
the input for the analysis. For sure, these candidates should also provide references to the corresponding tracks or clusters including covariance matrices etc. so that also these informations are easily accessible in the analysis part. Therefore one should think about how such a candidate (RhoCandidate ?) should look like.
|
I think this is already inside the rho package. The user needs just momentum and pid. But the user should be able also to perform his pid, or better to perform the standard pid for his channel, which could be different from another channel.
Ideas on class design about this tracking+pid+analysis are welcome. My personal idea is already inside the code, but I would like to listen to other opinions.
|
|
|
|
|
|
| Re: Strategy discussion on Track objects [message #8383 is a reply to message #8381] |
Fri, 01 May 2009 18:08 |
|
Anonymous Poster
|
|
From: *pool.einsundeins.de
|
|
Hi,
I have some question: Does PndTrack have extrapolation capabilities? If not, who is going to add them and how? Or maybe this is not what PANDAroot wants? I still dont get this point clearly.
About the PndTrackCand: How does it work? Does it hold indices to the hits that are used in this track? In genfit we have a TrackCand, which basically holds 2 standard vectors of integers: One for detId of the hit and one for the index in the corresponding TClonesArray of hits (e.g. PndTpcClusters or some MCpoints). What information is in PndTrackCand? I am sure we can convert it.
What do I need to do to make PndTrack objects. Is there just some constructor which takes position, momentum, etc.? I could implement a method in the Track object of genfit which returns such a PndTrack.
Cheers, Christian
|
|
|
|
|
|
|
|
|
|
| Re: Strategy discussion on Track objects [message #8480 is a reply to message #8473] |
Mon, 11 May 2009 11:39 |
|
Anonymous Poster
|
|
From: *natpool.mwn.de
|
|
Hi,
could somebody please provide with a description on how to use the PndTrack* classes?
Especially: What exactly does the hit ID in the PndTrackCandHit stand for?
And what should I put for rho?
I am willing to do the job, but I simply cant do it until I gut the information I need.
Cheers, Christian
|
|
|
|
|
|
|
|
|
|
| Re: Strategy discussion on Track objects [message #8514 is a reply to message #8484] |
Mon, 11 May 2009 23:02 |
|
Anonymous Poster
|
|
From: *pool.einsundeins.de
|
|
Hi,
in order to make a PndTrack I need to give FairTrackPar for the first and last points. I looked into these files. First I would like to point out that in the header file the constructor is declared as
/** Constructor with all variables **/
FairTrackPar(Double_t x, Double_t y, Double_t z,
Double_t fx, Double_t fy, Double_t fz, Double_t q);
And then in the cxx file it is defined as
FairTrackPar::FairTrackPar(Double_t x, Double_t y, Double_t z,
Double_t px, Double_t py, Double_t pz, Double
_t q)
: fX (x),
fY (y),
fZ (z),
fDX (x),
fDY (y),
fDZ (z),
fPx (px),
fPy (py),
fPz (pz),
fDPx (px),
fDPy (py),
fDPz (pz),
fQp (0),
fDQp (0),
fq (q)
{
This different naming of variables is strictly speaking not forbidden in C++, but it is very confusing. Please correct it to clarify.
I guess the paramters px,py,pz in the cxx file mean the momentum of the particle. But what about all errors and covariances? In this class there arent any data fields for covariances.
Am I doing something wrong here? Am I supposed to use some derived class? Please clarify this.
Cheers, Christian
|
|
|
|
Goto Forum:
Current Time: Sun Apr 28 16:04:14 CEST 2024
Total time taken to generate the page: 0.01104 seconds
|
GSI Forum
Search
Help
Members
Login
Home
