GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Tracking » Official code for tracking TDR
icon4.gif  Official code for tracking TDR [message #11603] Wed, 23 March 2011 14:35 Go to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Dear all tracking developers,
I would like to ask you which will be the official code we have to run for the grid massive data production.

As far as I have understood, many "open points" of my slides are already fixed or they are going to be fixed soon. For this reason I ask you here which tasks we have to use exactly for data production, for digitization, for the event mixing, for the MVD+CT+GEM global tracking and for de dE/dx.

Please write here when the code is in svn, when you are ready, so that we can start at least to run some tests.
Re: Official code for tracking TDR [message #11604 is a reply to message #11603] Wed, 23 March 2011 18:13 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *gsi.de
Stefano Spataro wrote on Wed, 23 March 2011 14:35

Dear all tracking developers,
I would like to ask you which will be the official code we have to run for the grid massive data production.

As far as I have understood, many "open points" of my slides are already fixed or they are going to be fixed soon. For this reason I ask you here which tasks we have to use exactly for data production, for digitization, for the event mixing, for the MVD+CT+GEM global tracking and for de dE/dx.

Please write here when the code is in svn, when you are ready, so that we can start at least to run some tests.



Hi,
since some days ago I put in the svn repository the class that does the mixing of background events.
The class is in
PndMixBackgroundEvents.cxx and .h
in the directory
$VMCWORKDIR/sttmvdtracking

Briefly I will put the demo Macros showing how to do the mixing
which, by the way, affect the STT and MVD detectors only for
the time being.
Tschuess ! Gianluigi
Re: Official code for tracking TDR [message #11606 is a reply to message #11603] Fri, 25 March 2011 15:14 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *gsi.de
Stefano Spataro wrote on Wed, 23 March 2011 14:35

Dear all tracking developers,
I would like to ask you which will be the official code we have to run for the grid massive data production.

As far as I have understood, many "open points" of my slides are already fixed or they are going to be fixed soon. For this reason I ask you here which tasks we have to use exactly for data production, for digitization, for the event mixing, for the MVD+CT+GEM global tracking and for de dE/dx.

Please write here when the code is in svn, when you are ready, so that we can start at least to run some tests.



I have just put the Macro

runPreliminaryMvdReco.C

in pandaroot/macro/sttmvdtracking in the repository.

This Macro takes as input the simulation, params and digi
root files of the DPM Background events and produces an output
file (Mix_Generation_reco.root) with reconstructed events.

The Mix_Generation_reco.root contains the Mvd hits TClonesArray
of the background, which are necessary later for the mixing
of physics with bkg events in the STT AND MVD analysis.

I hope very shortly I can put in svn the Macro for actually doing the mixing and subsequent analysis with the usual STT or STT+Mvd Pattern Recognition etc.
For that I have to wait for an answer from Tobias who has to please change slightly the way the input TClonesArray name is given to the Mvd Riemann Pattern Recognition.

Please stay tuned, cheers Gianluigi
Re: Official code for tracking TDR [message #11686 is a reply to message #11606] Wed, 20 April 2011 12:28 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Hi,
I have checked pandaroot/macro/sttmvdtracking/runPreliminaryMvdReco.C, but this has only the PndMvdClusterTask, which is already present in the digi macro. Probably I have missed something...

However, I have created a folder on macro/run/tdrct, for the macros for the central tracked TDR. We will run them on teh GRID.
At present I have simply copied the macros from dc4.

I would ask to tracking developers to modify directly them to add all your changes in the task list, so that at least we start to know what we should run.

Regards.
Re: Official code for tracking TDR [message #11689 is a reply to message #11686] Wed, 20 April 2011 14:43 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *gsi.de
Stefano Spataro wrote on Wed, 20 April 2011 12:28

Hi,
I have checked pandaroot/macro/sttmvdtracking/runPreliminaryMvdReco.C, but this has only the PndMvdClusterTask, which is already present in the digi macro. Probably I have missed something...

However, I have created a folder on macro/run/tdrct, for the macros for the central tracked TDR. We will run them on teh GRID.
At present I have simply copied the macros from dc4.

I would ask to tracking developers to modify directly them to add all your changes in the task list, so that at least we start to know what we should run.

Regards.



Dear Stefano,
I took advantage of the fact that the PndMvdClusterTask is already present in the Grid digi macro to semplify the procedure.
Now only the reconstruction macro is necessary and present in the repository :
macro/sttmvdtracking/runrecoMix.C

This macro needs the background input digi file name to be :

Mixed_digi.root

(for instance : the DPM event digi file).

So, please forget about the runPreliminaryMvdReco.C

Gianluigi
Re: Official code for tracking TDR [message #11699 is a reply to message #11689] Thu, 21 April 2011 10:08 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Fine,
but I would like also to know what should stay inside the dpm background simulation and digitization. Only stt or also mvd? Up to which level? I suppose it is meaningless to run digitization also for emc or other detectors, considering that the bg file will be useful only for CT digi mixing. Am i right?

And another good question would be how much bg event one should run for each "signal" event. I.e., if I want to run 1000 physics events, how many dpm events should I run?

[Updated on: Thu, 21 April 2011 10:08]

Report message to a moderator

Re: Official code for tracking TDR [message #11701 is a reply to message #11699] Thu, 21 April 2011 13:51 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *gsi.de
Stefano Spataro wrote on Thu, 21 April 2011 10:08

Fine,
but I would like also to know what should stay inside the dpm background simulation and digitization. Only stt or also mvd? Up to which level? I suppose it is meaningless to run digitization also for emc or other detectors, considering that the bg file will be useful only for CT digi mixing. Am i right?

And another good question would be how much bg event one should run for each "signal" event. I.e., if I want to run 1000 physics events, how many dpm events should I run?


As far as the STT is concerned, in the dpm background simulation and digitization there should be Mvd and Stt.

As far as the TPC is concerned, there should be Mvd and TPC. Ask
please confirmation to the Muenich people.


IN PRINCIPLE for Stt the should be
20x10**6 x 200 x10**(-9) x 2 = 8 background events per physics event
[ this is caused by the 20 MHz interaction rate in Panda and
the maximum drift time of 200 nsec in the Straws].


IN PRINCIPLE for the TPC, which I believe has a total volume drift time of 50 microsec, a similar calculation gives

20x10**6 x 50x10**(-6) = 1000 background events per physics event.

I say IN PRINCIPLE because if the bkg events are too many we may think of randomly reusing some of them.


Gianluigi
Re: Official code for tracking TDR [message #11702 is a reply to message #11701] Thu, 21 April 2011 15:01 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
I suppose the correct association is done inside the mixing task. Should one set the frequency, or is it hardcoded?
Dpm should be also modified in order to correct properly for the elastic cutoff. Or should this normalization be set inside the mixing task?

It is still unclear which theta_min we should use in the DPM simulation.

Re: Official code for tracking TDR [message #11703 is a reply to message #11702] Thu, 21 April 2011 15:18 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *gsi.de
Stefano Spataro wrote on Thu, 21 April 2011 15:01

I suppose the correct association is done inside the mixing task. Should one set the frequency, or is it hardcoded?
Dpm should be also modified in order to correct properly for the elastic cutoff. Or should this normalization be set inside the mixing task?

It is still unclear which theta_min we should use in the DPM simulation.




I am not sure what you mean by correct association, but
yes, the correct background mixing and is correctly done - for STT- in the runreco.
As you know the STT reconstruction code is still under development. However I will put an example of runreco.C that includes all tasks presently finished and tested in
pandaroot/macro/sttmvdtracking
and also, if you want, in
pandaroot/macro/run/tdrct/run_reco_sttcombi.C

Gianluigi
Re: Official code for tracking TDR [message #11704 is a reply to message #11703] Thu, 21 April 2011 15:25 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Gianluigi Boca wrote on Thu, 21 April 2011 15:18


I am not sure what you mean by correct association,



I mean if the task knows exactly how many events/hits should be taken from the DPM background file, if this number is fixed or if it depends from the rate you set by hands, and if the task should correct the rate for the theta_min, or if this should be done by something else.

Re: Official code for tracking TDR [message #11705 is a reply to message #11704] Thu, 21 April 2011 15:42 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *gsi.de
Stefano Spataro wrote on Thu, 21 April 2011 15:25

Gianluigi Boca wrote on Thu, 21 April 2011 15:18


I am not sure what you mean by correct association,



I mean if the task knows exactly how many events/hits should be taken from the DPM background file, if this number is fixed or if it depends from the rate you set by hands, and if the task should correct the rate for the theta_min, or if this should be done by something else.




to answer your questions :

1) the reco tasks knows how many event of bkg mix to a physics event. That number is NOT fixed, and it is based on a 20 MHz interaction rate, value that is presently HARDCODED. I can easily modify the code in order
to have some external parameter for the interaction rate.

2) The STT mixing code at some point HAS TO TAKE INTO ACCOUNT
THE N. OF BACKGROUND EVENTS 'invisible' so to speak, to the
STT (and TPC) apparatus. Presently in the code THERE IS NOT
THIS FEATURE but it is very easy to add it.
As you know the issue of how many 'invisible' background events are there in Panda and what is the Theta_min angle for the DPM bkg generation has been solved in principle by a discussion with Aida during the last March meeting, and Bernd Ketzer is supposed to send out a brief written summary. In the summary there will be also the Theta_min value and the percentage of 'invisible' background.

FROM THE GRID POINT OF YOU, you need to know only the Theta_min value because STT MIXING CODE WILL TAKE INTO ACCOUNT THE INVIIBLE BKG.

Cheers
Gianluigi
Re: Official code for tracking TDR [message #11720 is a reply to message #11686] Tue, 26 April 2011 18:01 Go to previous messageGo to next message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *pv.infn.it
Hi Stefano,
I just uploaded to svn the changes to add the GEM extension to the reco tasks in the tdrct directory.

I changed also the name of the input/output branches in the Kalman. In fact, as the GEM extension works now, it copies all the SttMvdTracks found by STT + MVD PR to the SttMvdGemTracks and adds the GEM hits where possible. I know this is not a good solution: it was foreseen to queue somehow the GEM extension directly to the STT + MVD PR, but this had to be posponed due to the many others things to do (first of all for me: have the GEM extension working!).
We will find a way to speed up things and not to occupy too much space: I think that for the final production we might think to put the persistency off for the SttMvdTrack and do the analysis on the SttMvdGemTracks: this should work fine do decrease the disk space needed. I imagine that copying the objects still takes some time... if I can I will find a way to avoid this too.

For now, please remember that the GEM extension still needs one fix to avoid the same GEM hits to be added to more than one track, but you can try it (if you want search for crashes Wink) since it should work also as it is now.
Ciao,
Lia.

Re: Official code for tracking TDR [message #11733 is a reply to message #11720] Tue, 03 May 2011 11:35 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Dear all,
I have put into macro/run/tdrct the full chain that should be run for the signal production for STT.
The list is in README_STT.TXT, and consists in macros in the following order:

BG sim + digi
run_sim_stt_dpm.C
run_digi_stt_dpm.C


SIGNAL sim + digi
run_sim_stt_evt.C
run_digi_stt_evt.C


Mixing and reconstruction:
run_reco_stt_mix.C
run_pid_stt_mix.C


I have used a dummy .dec file and a dummy pbar momentum, you should modify the values as you need.

I would like to ask experts to take a look, to check if I am forgetting something or not.
I would like to have also the task list for TPC, to prepare such kind of macros.


Few comments from my side:

  • Sim and Digi could be run in the same macro, in order to save disk space and to not store the points. Unfortunately Mvd and Stt digi tasks do not allow this (while emc does), if you run digitization together with simulation you have crashes.
  • In theory reco ad pid could run on the same level, if needed
  • If you think some data objects could be removed from the file, just tell me. if you think that it would be better to switch off something, i.e. PID detectors, just tell me and we can discuss
  • I have added also FTS geometry. If requested, Ralf ideal track finder for forward spectrometer could be added, if stable enough


I think for the moment is over, I wait for comments and remarks.


Re: Official code for tracking TDR [message #11737 is a reply to message #11733] Tue, 03 May 2011 17:28 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *gsi.de
I looked at those Macros, everything looks fine as far as I can tell

Gianluigi

Stefano Spataro wrote on Tue, 03 May 2011 11:35

Dear all,
I have put into macro/run/tdrct the full chain that should be run for the signal production for STT.
The list is in README_STT.TXT, and consists in macros in the following order:

BG sim + digi
run_sim_stt_dpm.C
run_digi_stt_dpm.C


SIGNAL sim + digi
run_sim_stt_evt.C
run_digi_stt_evt.C


Mixing and reconstruction:
run_reco_stt_mix.C
run_pid_stt_mix.C


I have used a dummy .dec file and a dummy pbar momentum, you should modify the values as you need.

I would like to ask experts to take a look, to check if I am forgetting something or not.
I would like to have also the task list for TPC, to prepare such kind of macros.


Few comments from my side:

  • Sim and Digi could be run in the same macro, in order to save disk space and to not store the points. Unfortunately Mvd and Stt digi tasks do not allow this (while emc does), if you run digitization together with simulation you have crashes.
  • In theory reco ad pid could run on the same level, if needed
  • If you think some data objects could be removed from the file, just tell me. if you think that it would be better to switch off something, i.e. PID detectors, just tell me and we can discuss
  • I have added also FTS geometry. If requested, Ralf ideal track finder for forward spectrometer could be added, if stable enough


I think for the moment is over, I wait for comments and remarks.




Re: Official code for tracking TDR [message #11739 is a reply to message #11733] Wed, 04 May 2011 11:18 Go to previous messageGo to next message
Ralf Kliemt is currently offline  Ralf Kliemt
Messages: 507
Registered: May 2007
Location: GSI, Darmstadt
first-grade participant

From: *pool.mediaWays.net
Stefano Spataro wrote on Tue, 03 May 2011 11:35


I would like to ask experts to take a look, to check if I am forgetting something or not.


From my side it's OK.
Stefano Spataro wrote on Tue, 03 May 2011 11:35


  • Sim and Digi could be run in the same macro, in order to save disk space and to not store the points. Unfortunately Mvd and Stt digi tasks do not allow this (while emc does), if you run digitization together with simulation you have crashes.



I fixed a bug with the PndSdsDetector persistence flag.
If you want to save some data volume you can do:

PndMvdDetector::SetPersistance(kFALSE) and/or
PndMvdDigiTask::SetPersistance(kFALSE) and/or
PndMvdDigiTask::SetPersistance(kFALSE)

Cheers.

Ralf
Re: Official code for tracking TDR [message #11742 is a reply to message #11739] Thu, 05 May 2011 15:14 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
I have created the first analysis folder, psi3770, with also the .dec file and the dpm tuned at the proper energy. Only STT version there, up to now I have no feedback from TPC group on which code to use.

Slowly I will add further folders, once we will establish the models to use.


I have tried simulating 1000 dpm events and 100 evtgen models.
At the reco level (as explained in my previous post), I have the following crash (still with feb11):

*** PndRecoKalmanFit::Exec	Genfit Exception: trk->addHitVector 
from PndMixBackgroundEvents : in this evt 7 evts of bkg are added, with the following times :
	t = -119.7
	t = -166.3
	t = 1.593
	t = 12.03
	t = 68.07
	t = 70.01
	t = 185.0
Found Tracks: 36 in event no. 86
----------------
glp_set_mat_col: j = 11; ind[5] = 0; row index out of range
Error detected in file glpapi01.c at line 878


I have tried with may11 and the crash does not appear, but I have not used exactly the same seed and I would like to be sure that we will not fall again in this crash.

A general comment, I have seen many log messages that I think should be avoided, in order to reduce the disk space for log messages.

Re: Official code for tracking TDR [message #11743 is a reply to message #11742] Thu, 05 May 2011 15:54 Go to previous messageGo to next message
Felix Boehmer is currently offline  Felix Boehmer
Messages: 149
Registered: May 2007
Location: Munich
first-grade participant

From: *natpool.mwn.de
Hi Stefano,

I am currently finalizing the geometry for the TPC which has to be in the MC production.
Please give me the weekend for some tests, then I will look over the macros next week.

We also have to talk about the parameter file handling again, I think, as well as the final method on how to do the mixing in the TPC case. If I understood correctly, you claim that it would be feasible to run fully mixed events for the TPC for all channels on the grid, even considering execution times of roughly 30 min/event?


Cheers

Felix
Re: Official code for tracking TDR [message #11744 is a reply to message #11743] Thu, 05 May 2011 16:49 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Hi,

Felix Boehmer wrote on Thu, 05 May 2011 15:54


We also have to talk about the parameter file handling again, I think, as well as the final method on how to do the mixing in the TPC case. If I understood correctly, you claim that it would be feasible to run fully mixed events for the TPC for all channels on the grid, even considering execution times of roughly 30 min/event?



I have never claimed that. I had never the chance to test the reconstruction code, therefore it is not clear to me how much time we will really need to do the mixed reconstruction. The background production should not take so much time on the grid, but the mixed reconstruction will be our problem.
However, for sure something in the reco code should be done in order to make everything faster, even because it is not feasible to spend half an hour for an event once we will have real data.

For sure everything should be tested as soon as possible, in order to be able to react quickly for our production. But I suppose the only improvements could come only within the reco/mixing code.

Re: Official code for tracking TDR [message #11747 is a reply to message #11742] Fri, 06 May 2011 20:59 Go to previous messageGo to next message
Gianluigi Boca is currently offline  Gianluigi Boca
Messages: 177
Registered: March 2004
first-grade participant
From: *pv.infn.it
Stefano Spataro wrote on Thu, 05 May 2011 15:14

I I have tried simulating 1000 dpm events and 100 evtgen models.
At the reco level (as explained in my previous post), I have the following crash (still with feb11):

*** PndRecoKalmanFit::Exec	Genfit Exception: trk->addHitVector 
from PndMixBackgroundEvents : in this evt 7 evts of bkg are added, with the following times :
	t = -119.7
	t = -166.3
	t = 1.593
	t = 12.03
	t = 68.07
	t = 70.01
	t = 185.0
Found Tracks: 36 in event no. 86
----------------
glp_set_mat_col: j = 11; ind[5] = 0; row index out of range
Error detected in file glpapi01.c at line 878


I have tried with may11 and the crash does not appear, but I have not used exactly the same seed and I would like to be sure that we will not fall again in this crash.




Hi Stefano,
I updated
sttmvdtracking/PndMixBackgroundEvents.cxx
and eliminated the debug printouts.
As far as the crash is concerned, I am investigating it; Susanna got the same type of crash last week when running the reconsruction, I let the collaboration know as soon as I fix it

Cheers Gianluigi
Re: Official code for tracking TDR [message #11753 is a reply to message #11742] Mon, 09 May 2011 17:45 Go to previous messageGo to next message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *pv.infn.it
Hi Stefano,
I am testing the macros in macro/run/tdrct.
When running run_reco_stt_mix.C there are a lot of errors like:
*** PndRecoKalmanFit::Exec	Genfit Exception: trk->addHitVector 
due to the fact that in the Kalman Task only the TClonesArray of "non mixed" hits are loaded.
In this way the HitProducers are set via the RecoHitFactory with the detID of STTHit, MVDHitsPixel..., i.e. the non mixed arrays, but when reading from the SttMvdGemTrackCand the list of found hits, they are "mixed" hits, coming from STTHitMix, MVDHitsPixelMix... i.e. coming from different TClonesArray, which means with different detIDs. At this point genfit cannot handle them properly and gives the errror.

Is it possible to add also to the Kalman Task the possibility to set directly from the macro the names of the collection of hits to be used?

In this way we keep the non mixed name as default and have the possibility to switch to the "mixed mode" when needed.
What do you think?
Ciao,
Lia.
Re: Official code for tracking TDR [message #11762 is a reply to message #11753] Tue, 10 May 2011 12:20 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *w90-20.abo.wanadoo.fr
Hi Lia,
this should not be so difficult. It is just a matter to add in GenfitTools/recotasks/PndRecoKalmanFit class other recohitfactories loading the "mixed" TCA.

Unfortunately this week I am not in my office and I cannot do this change before next week, but probably you could do it easily by yourself.

The other thing is that the PndTrackCand should be filled with the "correct" detectorId, i.e. the correct name of the TCA.
Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash [message #11788 is a reply to message #11603] Thu, 12 May 2011 14:08 Go to previous messageGo to next message
Dima Melnychuk is currently offline  Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...
first-grade participant
From: *fuw.edu.pl
Dear colleagues,

Running macros in /run/tdrct/psi3770

run_sim_stt_evt.C
run_digi_stt_evt.C
run_reco_stt_evt.C

I observe the following crash of PndMvdRiemannTrackFinder.

#9  <signal handler called>                                                                       
#10 0x05637ce3 in PndMvdRiemannTrackFinder::GetMaxSZChi2 (this=0xbf870598,                        
    radius=1.9647063263619289, dip=0.99201173646785301, sign=false)                               
    at /home/dimam/pandaroot/pandaroot/mvd/MvdTracking/PndMvdRiemannTrackFinder.cxx:440           
#11 0x056372aa in PndMvdRiemannTrackFinder::CheckSZ (this=0xbf870598, aTrack=                     
    ...)                                                                                          
    at /home/dimam/pandaroot/pandaroot/mvd/MvdTracking/PndMvdRiemannTrackFinder.cxx:339           
#12 0x05636abc in PndMvdRiemannTrackFinder::GetStartTracks (this=0xbf870598)                      
    at /home/dimam/pandaroot/pandaroot/mvd/MvdTracking/PndMvdRiemannTrackFinder.cxx:292           
#13 0x05634e2c in PndMvdRiemannTrackFinder::FindTracks (this=0xbf870598)                          
    at /home/dimam/pandaroot/pandaroot/mvd/MvdTracking/PndMvdRiemannTrackFinder.cxx:95            
#14 0x056309fb in PndMvdRiemannTrackFinderTask::Exec (this=0x91db780,                             
    opt=0x2cfb5e0 "")                                                                             
    at /home/dimam/pandaroot/pandaroot/mvd/MvdTracking/PndMvdRiemannTrackFinderTask.cxx:127       
#15 0x00471f31 in TTask::ExecuteTasks (this=0x8737668, option=0x2cfb5e0 "")                       
    at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:312                      
#16 0x00471d47 in TTask::ExecuteTask (this=0x8737668, option=0x2cfb5e0 "")                        
    at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:275                      
#17 0x02c4eddb in FairRunAna::Run (this=0x87375f0, Ev_start=0, Ev_end=10)                         
    at /home/dimam/pandaroot/pandaroot/base/FairRunAna.cxx:272                              


The whole log message
Toggle Spoiler


The same crush is with macros in /macro/sttmvdtracking

I use may11 external packages and it looks like this crush appeared after installing them. Unfortunately due to the disk space I deleted feb11 external packages on my computer and cannot confirm if new external packages is the reason for crush.

The crush is caused by division by zero in
PndMvdRiemannTrackFinder.cxx:440

but after more detailed investigation of PndMvdRiemannTrackFinder I haven't found where initialization of fCutChi2H takes place to check what causes this division.

So first of all could somebody confirm the crush and if it is reproduced, can experts look into PndMvdRiemannTrackFinder.

Best regards,

Dima
Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash [message #11789 is a reply to message #11788] Thu, 12 May 2011 15:43 Go to previous messageGo to next message
Elisa Fioravanti is currently offline  Elisa Fioravanti
Messages: 84
Registered: January 2008
continuous participant
From: *fe.infn.it
Hello,

I run the macros in /run/tdrct:

run_sim_stt_evt.C
run_digi_stt_evt.C
run_reco_stt_evt.C

with the external package version of 15.02.2011
and I have not this error.

I'm trying to install now the new external package.

Perhaps, it could be a problem of the new external packages, hope that experts can solve the problem.

best
Elisa
Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash [message #11803 is a reply to message #11789] Wed, 18 May 2011 17:19 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *4-87-r.retail.telecomitalia.it
Has the experts checked what is going wrong with the MvdRiemann?
Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash [message #11815 is a reply to message #11803] Thu, 19 May 2011 14:02 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
I have the same crash in my pc, with may11.
The problem comes from line 440 of mvd/MvdTracking/PndMvdRiemannTrackFinder.cxx :

int binTh=int(floor((Theta-minTh)*fCutChi2H->GetYaxis()->GetNbins()/(maxTh-minTh)))+1;


because minTh is "nan".

In particular

maxTh 9.271e-311
minTh nan
minPt 1.141e+243
maxPt 8.907e-315

I have not understood where the fCutChi2H is initialized, and why it has so dummy values.

Can expert fix it in a short time? The analyst for the tracking TDR cannot run the reconstruction at this moment,a nd we do nto have so much time.
Many thanks in advance.



Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash [message #11817 is a reply to message #11803] Thu, 19 May 2011 14:09 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
From: *ikp.kfa-juelich.de
I am working on it.
Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash [message #11820 is a reply to message #11815] Thu, 19 May 2011 14:24 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
From: *ikp.kfa-juelich.de
Hi Stefano,

for me it runs smoothly without any crash for 500 events. Does it crash directly or after some events?

In my understanding these lines of code should never be reached, because this histograms are not set. I will give now a dedicated initialization of the pointer to 0.

Can you please check if it still crashes?


Cheers,

Tobias
Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash [message #11822 is a reply to message #11820] Thu, 19 May 2011 14:49 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Hi,
it was crashing exactly at the first event.
Now it seems to work. Thanks.
Official code for tracking TDR - PndSttMvdGemTracking problems [message #11824 is a reply to message #11822] Thu, 19 May 2011 15:11 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
But now I have seen that the task PndSttMvdGemTracking is providing such messages:

Error in <TClonesArray::At>: index -16395 out of bounds (size: 546, this: 0xb2b3180)


It seems the code is taking wrong negative track_id values, for some reason.

Fixes are welcome, of course Smile
Re: Official code for tracking TDR - PndSttMvdGemTracking problems [message #11832 is a reply to message #11824] Thu, 19 May 2011 18:13 Go to previous messageGo to next message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *pv.infn.it
Quote:

But now I have seen that the task PndSttMvdGemTracking is providing such messages:
Error in <TClonesArray::At>: index -16395 out of bounds (size: 546, this: 0xb2b3180)
It seems the code is taking wrong negative track_id values, for some reason.


Ciao Stefano,
why "track_id"? Did you already find which of the calls to "TClonesArray::At" in the code is giving the error?
Lia.
Re: Official code for tracking TDR - PndSttMvdGemTracking problems [message #11833 is a reply to message #11832] Thu, 19 May 2011 18:17 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Not yet,
I have only found that the only task producing this message is the SttMvdGem one.
Re: Official code for tracking TDR - PndSttMvdGemTracking problems [message #11834 is a reply to message #11833] Fri, 20 May 2011 10:38 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Hi,
I am not sure, but I have seen a source of this At problem, not in PndSttMvdGemtracking but in PndSttMvdTracking.
Exactly, the wrong At (but in my case now it is positive) is a MC index in the function PndSttMvdTracking::getMCInfo, exacly line 9756:

	pMC = (PndMCTrack*) fMCTrackArray->At(MCTrack);


called by line 6169:

	getMCInfo( enne, &Cx, &Cy, &Rr);


The problem appears when "enne" is set in line 6139:

enne = FromStriptoMCTrack[ ListPixelHitsinTrack[jexp][i] ] ;


producing a dummy MCTrack ID. After this, I was not able to proceed further and the "experts" should be able to fix this.

Not clear to me why the MC information should be used in pattern recognition, maybe for some debug, but this is another topic.

Re: Official code for tracking TDR - PndSttMvdGemTracking problems [message #11836 is a reply to message #11834] Fri, 20 May 2011 11:58 Go to previous message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *pv.infn.it
Hi Stefano,

Quote:

I am not sure, but I have seen a source of this At problem, not in PndSttMvdGemtracking but in PndSttMvdTracking.


yes, I think so. I made some tests of the reconstruction commenting out the PndSttMvdGemTracking part and leaving the PndSttMvdTracking and the error is there. If I comment out also the PndSttMvdTracking it disappears.

It is also random, since if I reconstruct more than once the same events I get different errors, always of that kind:
Error in <TClonesArray::At>: index ... out of bounds ...

Quote:

Not clear to me why the MC information should be used in pattern recognition, maybe for some debug, but this is another topic.

I can answer for PndSttMvdGemTracking: the PndMCTrack was taken just to flag not primary tracks, the MC info was not used in the code, it was just there for debug purpose. Anyway, I put that part of code in a if(fEvaluate) statement so that it is used only if evaluation of performances is asked. By default that evaluation is set to false, so you should not see errors of this type coming from the PndSttMvdGemTracking anymore.

For PndSttMvdTracking, I leave it to Gianluigi Rolling Eyes
Ciao,
Lia.

Previous Topic: Reconstruction macro crash with may11 release
Next Topic: Simulation campaign for central tracker TDR
Goto Forum:
  


Current Time: Mon Oct 07 19:51:11 CEST 2024

Total time taken to generate the page: 0.00902 seconds