Home » PANDA » PandaRoot » Bugs, Fixes, Releases » TPC MVD and GEM correlators
| Re: TPC MVD and GEM correlators [message #12019 is a reply to message #12016] |
Thu, 16 June 2011 14:52   |
Felix Boehmer
Messages: 149
Registered: May 2007
Location: Munich
|
first-grade participant |
From: *gsi.de
|
|
Hi Stefano,
do you have the latest version of the KalmanTask? It looks like you don't and there is one of the RecoHitProducers not properly defined.
To your questions:
| Quote: |
Ca we move the tpc clusterization to the digi macro, or remove it in the digi? At present we are running the same code, even if with different parameters, twice
|
I removed the clustering from the reco macro.
| Quote: |
I suppose you do not need the mvdriemann code for the tpc+mvd tracking, unlike the stt case. Isn't it? (just to be sure)
|
You are right, I don't.
| Quote: |
You are running tpc tracking, and after kalman, then tpc+mvd, and kalman, tpc+mvd+gem, and kalman. Would it be much faster to run tpc tpc+mvd and tpc+mvd+gem only with the prefit values, and to run only a final kalman at the end? This would save a lot of time, a lot of crashes and memory usage, and I suppose in the prefit phase we do not need to "kalmanize" the tracks but only at the end for the fina parameters
|
What you describe was my first approach. However, using the MVD hits after TPC+MVD correlation in a fit gives better results for the (possibly very long) extrapolation into the GEMs. I would keep it that way. I agree that it is slow, but it is the best I have right now. The crashes are completely isoloated to GEANE extrapolations into the GEMs as far as I can tell right now... I am working on it, as I said.
| Quote: |
Which particle hypothesis are you using for the kalman?
Is there a way to reduce all those messages? They make the log output file large
|
The particle hypothesis is obtained from MC information isndie the PndTpcRiemannTrackingTask. I can build in a setter if you want to have manual control during the reco.
| Quote: |
I would strongly suggest to use the GenfitTools/recotask/PndRecoKalmanTask-Fit (as I have already told to Sebastian when he came back into the business, almost one month ago), because it is in the standard way and return directly a PndTrack object from another PndTrack object. Probably KalmanTask and PndRecoKalmanTask/Fit should just be compared, they are doing the same things but with different output. The main problem is that, if we run the KalmanTask, we have also to write a new task converting the GFTrack into PndTrack, while this job is already done in the PndRecoKalmanFit code. The PndTrack object is the starting point of the correlator to produce our TCandidate, without PndTrack users cannot run analysis
|
I can take a look at this after I have fixed all the other, more urgent problem. I would be very grateful if you could have a lokk at this. Probably the exchange would be a very technical task, but rather easy.
| Quote: |
Of course I will help for the coding, at least for the common parts.
|
You shouldn't have said that, see my answer above 
|
|
|
|
Current Time: Thu Apr 18 21:26:32 CEST 2024
Total time taken to generate the page: 0.01131 seconds
|
GSI Forum
Search
Help
Members
Login
Home
