GSI Forum - RDF feed
type: channel
description: GSI Helmholtzzentrum für Schwerionenforschung
items: Official code for tracking TDR
items: Re: Official code for tracking TDR
items: Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
items: Official code for tracking TDR - PndSttMvdGemTracking problems
items: Re: Official code for tracking TDR - PndSttMvdGemTracking problems

Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-03-23T13:35:20-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Gianluigi Boca
date: 2011-03-23T17:13:18-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Gianluigi Boca
date: 2011-03-25T14:14:41-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-04-20T10:28:26-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Gianluigi Boca
date: 2011-04-20T12:43:38-00:00

Re: Official code for tracking TDR
type: item
description: 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?
creator: StefanoSpataro
date: 2011-04-21T08:08:06-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Gianluigi Boca
date: 2011-04-21T11:51:15-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-04-21T13:01:12-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Gianluigi Boca
date: 2011-04-21T13:18:03-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-04-21T13:25:16-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Gianluigi Boca
date: 2011-04-21T13:42:04-00:00

Re: Official code for tracking TDR
type: item
description: 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 ) since it should work also as it is now. Ciao, Lia.
creator: Lia Lavezzi
date: 2011-04-26T16:01:10-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-05-03T09:35:26-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: Gianluigi Boca
date: 2011-05-03T15:28:41-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Ralf Kliemt
date: 2011-05-04T09:18:32-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-05-05T13:14:35-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Felix Boehmer
date: 2011-05-05T13:54:21-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-05-05T14:49:34-00:00

Re: Official code for tracking TDR
type: item
description: 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
creator: Gianluigi Boca
date: 2011-05-06T18:59:48-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: Lia Lavezzi
date: 2011-05-09T15:45:24-00:00

Re: Official code for tracking TDR
type: item
description: 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.
creator: StefanoSpataro
date: 2011-05-10T10:20:54-00:00

Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
type: item
description: 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 root [0] .x run_reco_stt_evt.C Add file name : evt_digi_stt.root Add file name : evt_points_stt.root Info in (PndGeoHandling::Instance): Making a new instance using the framework. [INFO ] The input consists out of the following trees and files: [INFO ] - cbmsim [INFO ] - evt_digi_stt.root [INFO ] - FriendTree_1 [INFO ] - evt_points_stt.root [INFO ] Geometry was not found in the input file we will look in the friends if any! [INFO ] The number of entr…
creator: Dima Melnychuk
date: 2011-05-12T12:08:41-00:00

Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
type: item
description: 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
creator: Elisa Fioravanti
date: 2011-05-12T13:43:46-00:00

Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
type: item
description: Has the experts checked what is going wrong with the MvdRiemann?
creator: StefanoSpataro
date: 2011-05-18T15:19:09-00:00

Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
type: item
description: 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.
creator: StefanoSpataro
date: 2011-05-19T12:02:04-00:00

Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
type: item
description: I am working on it.
creator: Tobias Stockmanns
date: 2011-05-19T12:09:17-00:00

Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
type: item
description: 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
creator: Tobias Stockmanns
date: 2011-05-19T12:24:16-00:00

Re: Official code for tracking TDR - PndMvdRiemannTrackFinder crash
type: item
description: Hi, it was crashing exactly at the first event. Now it seems to work. Thanks.
creator: StefanoSpataro
date: 2011-05-19T12:49:16-00:00

Official code for tracking TDR - PndSttMvdGemTracking problems
type: item
description: 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
creator: StefanoSpataro
date: 2011-05-19T13:11:37-00:00

Re: Official code for tracking TDR - PndSttMvdGemTracking problems
type: item
description: 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.
creator: Lia Lavezzi
date: 2011-05-19T16:13:52-00:00

Re: Official code for tracking TDR - PndSttMvdGemTracking problems
type: item
description: Not yet, I have only found that the only task producing this message is the SttMvdGem one.
creator: StefanoSpataro
date: 2011-05-19T16:17:10-00:00

Re: Official code for tracking TDR - PndSttMvdGemTracking problems
type: item
description: 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.
creator: StefanoSpataro
date: 2011-05-20T08:38:56-00:00

Re: Official code for tracking TDR - PndSttMvdGemTracking problems
type: item
description: 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 Ciao, Lia.
creator: Lia Lavezzi
date: 2011-05-20T09:58:34-00:00