Home » PANDA » PandaRoot » Tracking » Forward spectrometer tracking
| Forward spectrometer tracking [message #8735] |
Tue, 02 June 2009 14:13  |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *kph.uni-mainz.de
|
|
Dear trackers,
I'm trying to make the tracking with DCH, GEM and MvD detectors in Forward spectrometer.
I found a tracking tools with DCH, it works very fine.
And GEM with 4 stations are partly implemented and doesn't nicely response in all momentum range.
MvD can use in principle, but it is not combined with other(GEM, DCH) detectors.
I realize that there is still no global tracking with MvD+DCH+GEM.
But I expect some kind of combined DCH+MvD or DCH+Gem tools are available to use if someone already working for Forward spectrometer part.
Could you make some comment and give me useful informations about FS tracking?
Best wishes,
Donghee Kang
|
|
|
|
|
|
| Re: Forward spectrometer tracking [message #8738 is a reply to message #8736] |
Tue, 02 June 2009 15:04  |
|
Anonymous Poster
|
|
From: *pool.einsundeins.de
|
|
Hi,
what do you mean with 'there is no global tracking for MVD, GEM & DCH'? It is in principle true, but all these groups use genfit. So to combine these into one global tracking is only an organizational problem, not a technical one.
Donghee: Are you maybe interested in trying this task? I guess that is all the 3 experts from the detector groups show you their macros, it shouldnt be a big problem. You would have to modify the recotasks/KalmanTask.cxx very slightly to contain hit producers for the three detectors. A hit producer is code which does for example:
for detector id 6, I take the following TClonesArray of reconstructed clusters and for each one I call the ctor SomeRecoHit(SomeCluster*).
Then you would need a pattern recognition which makes one TrackCand object containing all clusters from the 3 detectors, which should be possible by combining all the three pattern recognitions together (this would be in something like ForwardGlocalPatternRecoTask or so). In this task you would set up the Track objects which are then fit in the KalmanTask.
If you would like to try this, I could tell you a little more with the TPC example, how it is done.
Cheers, Christian
|
|
|
|
|
|
| Re: Forward spectrometer tracking [message #8740 is a reply to message #8739] |
Tue, 02 June 2009 15:33 |
Aleksandra Wronska
Messages: 38
Registered: May 2006
Location: Cracow
|
continuous participant |
From: *if.uj.edu.pl
|
|
Hi,
it is not quite true that there is nothing concerning forward tracking. Recently Radek tried (with a little bit of my help) to merge information from gem and dch. The results of our efforts you can find in the fwd directory and the corresponding macro/fwd directory.
It is very simple for the time being, using MCtruth info in quite many places of the code, but still IT DOES NOT WORK as expected. Moreover, even if one switches off one of the detectors, e.g. gems, one would expect to reproduce results obtained in the "stand-alone" detector's code, e.g. in the dch macros. Unfortunately, it is not the case, so most likely there is still a problem somewhere in this code, which needs more careful debugging. Nevertheless, it is a good starting point for further development. Feel invited to do that.
regards,
ola
|
|
|
|
| Re: Forward spectrometer tracking [message #8742 is a reply to message #8739] |
Tue, 02 June 2009 15:43 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *kph.uni-mainz.de
|
|
Dear Christian,
That is surely great idea!
I would be really happy, if I can join this subject and if there are no other argument. I will try to give some small contribution for the forward spectrometer tracking.
I would like to discuss dch and gem standalone tracking.
If I look and run dch tracking macro, i have very reasonable spectra. you can also find dch_mom.eps _theta.eps _resolution.eps
and xyview.eps, that are defined by dch tracking.
Blue one is reconstruced from dch tracking, red for generated one in one dimension plot.
x and y units in 2D plot are [m] meter.
But if I have tested gem alone, the result is changing dramatically. I have a look all hits information, which is prepared in GEM macro, most of hits are dedicated near the 0.5cm radius in 4 station GEM, however identified tracking in GEM are located far way at roughly 50cm.
As well as reconstruction efficiency are quite bad.
Roughly 20% events are only reconstruced in GEM stations.
I think that GEM has some problem in the tracking.
Could you confirm this?
Best wishes,
Donghee Kang from Mainz
|
|
|
|
|
|
| Re: Forward spectrometer tracking [message #8762 is a reply to message #8758] |
Wed, 03 June 2009 16:40 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Radek,
Thank you for your kind looking of my plots.
You are perfectly right in some point!
I agree that GEM acceptance is quite limited and difficult to use in my task.
Therefore we need helping of MvD and DCH.
You can now find some hit information and kinematic plots at GEM stations.
Gem_4stations.eps is the hit distribution, prepared originally in the GEM Macro.
Gem_xyview_zoom.eps is 2D hit infomation in x-y plane.
Gem_rzview.eps is the hit information in z-direction.
gem_mom.eps gem_theta.eps are the comparison with generated one.
ggem_resolution.eps is the correspoing resolution plot in 2D level.
Y-axis is the (mom_generated - mom_reconstructed) in the left panel
and the (theta_gen - theta_reco) for right panel.
If you see gem_theta.eps, the accptance is over 2.2 degrees.
However If I have a look the resolution for momentum and theta.
All resoltuions are really bad even if GEM succeed proton tracking for relatively large angle!
I'm wondering why GEM cannot make reasonable tracking with good resolution, when proton has large angle!
GEM stations should be fired in 4 stations. That mean they have already 4 hits, and I think that is enough information to try reconstruction.
Is it still not enouhg hits to perform that? This is my real question!
Thank you!
Donghee Kang
[Updated on: Wed, 03 June 2009 16:43] Report message to a moderator |
|
|
|
| Re: Forward spectrometer tracking [message #8778 is a reply to message #8740] |
Thu, 04 June 2009 13:29 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Radek, Aleksandrma
I'm trying to give a contribution for the tracking of forward spectrometer.
My task would be simle and a combining of mvd+gem+dch detectors as you can imagine.
As a first step, I made a copy of your nice macro in the pandaroot macro/fwd
/PndFwdPrepareKalmanTracks.cxx and /PndFwdKalmanTracks.cxx
I have a small question for the usage of the function RecoHitFactory::addProducer(detID, *hitProd)
To put certain hit procuder module in this hit register, one need to define or know detector ID.
If I have a look for example GEM and DCH case, kGEM and kDCH can be found.
Are these value kGEM and kDCH integer? Where are they initialized?
I couldn't read kGEM and kDCH in both PndFwdKalmanTracks.cxx and PndFwdPrepareKalmanTracks.cxx, also in each header they are not defined if I have checked correctly.
| Quote: |
fTheRecoHitFactory->addProducer(kGEM,new RecoHitProducer<PndGemHit,PndGemRecoHit>(gemHitArray));
|
Second question is the conceptional design of PndFwdPrepareKalmanTracks::Exec().
If I put mvd detector, the iteration must be starting from mvd, how do you think?
| Quote: |
std::cout << "Looping over " << nofGemTracks << " gem tracks" << endl;
for (Int_t igemtr=0; igemtr<nofGemTracks; igemtr++){
|
My last question is for the understanding of PndPrepareKalmanTracks code.
This code prepare a pattern recognition with many hits.
The preparation has been started with GEM tracks, and then looking DCH tracks.
At the end all hit(in GEM and DCH) distributions are used to build a track.
If I want to use MVD, then do I have to make Mvd track also? because GEM and DCH has some
kind of tracking container in this stage.
or Do you think that I can use MVD hit without MVD track container during preparation?
Do you have some idea?
Thank you for your time!
Donghee Kang
|
|
|
|
| Re: Forward spectrometer tracking [message #8791 is a reply to message #8778] |
Thu, 04 June 2009 17:33 |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Dear Donghee,
FIrst of all, the kMVD, kGEM, kDCH are defined in /trunk/pnddata/PndDetectorList.h.
As for the adddition of the MVD, I think that both for GEM and DCH, the PrepareKalmanTracks tasks are taking the existing detector local tracks and build the Tracks that are understood and worked on by the KalmanTask itself. We have decided to make the PndFwdPrepareKalmanTracks accordingly, so that it takes GEM and DCH local tracks and combines them into Tracks. For now the task is very bad designed, I have to admit it (I created this, Aleksandra would have made a better job), because it works only with the MC information available. In future implementations it should be changed, have to be changed, and probably the task of merging GEM and DCH tracks together should go into other task.
As for the second question, the iteration can start from MVD at the moment, but I think we have to agree on this later on. In fact I would think that merging the tracks between different detectors should start from a detector with smallest amount of tracks/smallest acceptance (I did not think a long time about the problem, just guestimating).
Last answer is that PrepareKalmanTracks is working on tracks, not on hits. So it combines (at the moment, see previous remarks) tracks from different detectors, and the hits are there only to be placed in the resulting Track object.
Hope that answers your questions
radek
|
|
|
|
|
|
|
|
| Re: Forward spectrometer tracking [message #8795 is a reply to message #8738] |
Thu, 04 June 2009 19:30 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Christian,
Thank you for your kind teaching. I have few question to work the FS tracking, efficiently.
I have few references, but every suggestions indicate slightly different way. That is a bit confusing!
If I have some misconcept, please corret me!
| Quote: |
1. You would have to modify the recotasks/KalmanTask.cxx very slightly to contain hit producers for the three detectors.
2. take the following TClonesArray of reconstructed clusters and for each one I call the ctor SomeRecoHit(SomeCluster*).
3. a pattern recognition which makes one TrackCand object containing all clusters from the 3 detectors
4. If you would like to try this, I could tell you a little more with the TPC example, how it is done.
|
Concerning your comment 1:
Actually, we don't need to use MVDPoint, PndDchPoint and GEMPoint class, which are produced in simulation file for the fitting purpose. Is it correct?
Thus, I'm going to use hit containers in the digi file.
GEMHit, MVDHitPixel, MVDHitsStrip and PndDchCylinderHit classes are probably important to use three detectors.
Concerning your comment 2 & 3.
DemoPatternRecoTask or PndDchPrepareKalmanTracks has roughly same structure.
I assume that these two file has only different name, but they have same purpose.
They make a track candidate from local track including local detector hits!
This procedure can be called a pattern recognition, is it right?
After this setp, we have now quasi-reconstructed track(candidate) and quasi-reconstructed hit(according quasi-reconstructed track).
Finally, in the Kalmantask, the actual fitting can be performed for all quasi-reconstructed track candidate and find real reconstructed track candidate when the kalma fits are finished successfully.
I have one trouble to make clear understanding.
I thought that a pattern recognition simply can be made only with hit information as suggested in DemoPatternRecoTask.
But for example, PndDchPrepareKalman prefer to use local track, which is defined with one detector component in digi procedure.
I expect that it doesn't matter what we use, because local track have some hit information in any case. This is only different approach, is it correct?
Concerning your comment 4.
Where is it? Could you show me that?
Thank you for your time!
Cheers, donghee
|
|
|
|
Goto Forum:
Current Time: Thu Nov 28 05:48:48 CET 2024
Total time taken to generate the page: 0.00757 seconds
|
GSI Forum
Search
Help
Members
Login
Home
