GSI Helmholtzzentrum für Schwerionenforschung
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.
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
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
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.
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
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?
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
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.
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
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.
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
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.
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.
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.
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
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.
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
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.
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
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.
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
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 entries in chain is 10 ************************************************************* initialisation for run id 1404218784 ************************************************************* Info in <TGeoManager::TGeoManager>: Geometry Geometry, default geometry created Warning in <TGeoManager::Init>: Deleting previous geometry: Geometry/default geometry Info in <TGeoManager::CloseGeometry>: Geometry loaded from file... Info in <TGeoManager::SetTopVolume>: Top volume is cave. Master volume is cave Info in <TGeoManager::Voxelize>: Voxelizing... Info in <TGeoNavigator::BuildCache>: --- Maximum geometry depth set to 100 Info in <TGeoManager::CloseGeometry>: 183783 nodes/ 5650 volume UID's in FAIR geometry Info in <TGeoManager::CloseGeometry>: ----------------modeler ready---------------- Container FairBaseParSet initialized from ROOT file. -I container name PndGeoSttPar ************************************************************* initialisation for run id 1404218784 ************************************************************* Container PndSensorNamePar initialized from ROOT file. Container PndGeoSttPar initialized from ROOT file. Gem_Disk1_Gem1_Sensor_kapton type 0 has 786 front and 4250 back channels Gem_Disk1_Gem6_Sensor_kapton type 2 has 4750 front and 9000 back channels Gem_Disk2_Gem1_Sensor_kapton type 0 has 786 front and 5350 back channels Gem_Disk2_Gem6_Sensor_kapton type 2 has 5850 front and 11200 back channels Gem_Disk3_Gem1_Sensor_kapton type 0 has 786 front and 7150 back channels Gem_Disk3_Gem6_Sensor_kapton type 2 has 7650 front and 14800 back channels PndGemDetectors initialized from Ascii file PndFieldCreator::SetParm() 0xd802ab0 ************************************************************* initialisation for run id 1404218784 ************************************************************* PndGemDetectors initialized from Ascii file Container PndMultiFieldPar initialized from ROOT file. OBJ: PndTransPar PndTransPar Trans. Field parameter container OBJ: PndDipole1Par PndDipole1Par Dipole Field parameter container OBJ: PndDipole2Par PndDipole2Par Dipole Field parameter container OBJ: PndSolenoid1Par PndSolenoid1Par Solenoid 1st region parameter container OBJ: PndSolenoid2Par PndSolenoid2Par Solenoid 2nd region parameter container OBJ: PndSolenoid3Par PndSolenoid3Par Solenoid 3rd region parameter container OBJ: PndSolenoid4Par PndSolenoid4Par Solenoid 4th region parameter container [INFO ] PndFieldMap: Reading field map from ROOT file /home/dimam/pandaroot/pandaroot/input/TransMap.0890.root [INFO ] PndFieldMap: Reading field map from ROOT file /home/dimam/pandaroot/pandaroot/input/DipoleMap1.0890.root [INFO ] PndFieldMap: Reading field map from ROOT file /home/dimam/pandaroot/pandaroot/input/DipoleMap2.0890.root [INFO ] PndFieldMap: Reading field map from ROOT file /home/dimam/pandaroot/pandaroot/input/SolenoidMap1.root [INFO ] PndFieldMap: Reading field map from ROOT file /home/dimam/pandaroot/pandaroot/input/SolenoidMap2.root [INFO ] PndFieldMap: Reading field map from ROOT file /home/dimam/pandaroot/pandaroot/input/SolenoidMap3.root [INFO ] PndFieldMap: Reading field map from ROOT file /home/dimam/pandaroot/pandaroot/input/SolenoidMap4.root ------------------------FairGeane::Init ()------------------------------ Loading Geant3 libraries ... Loading Geant3 libraries ... finished MZSTOR. ZEBRA table base TAB(0) in /MZCC/ at adr 741507463 2C328187 HEX MZSTOR. Initialize Store 0 in /GCBANK/ with Store/Table at absolute adrs 741616805 741507463 HEX 2C342CA5 2C328187 HEX 1A72A 0 relative adrs 108330 0 with 1 Str. in 2 Links in 5300 Low words in 4999970 words. This store has a fence of 16 words. MZLOGL. Set Log Level 0 for store 0 1***** GEANT Version 3.21/11 Released on 100298 0***** Correction Cradle Version 0.1100 MZDIV. Initialize Division Constant in Store 0 NW/NWMAX= 20004000000, MODE/KIND= 1 2 Division 20 initialized. MZLINK. Initialize Link Area /GCLINK/ for Store 0 NL/NS= 20 20 MZLINK. Initialize Link Area /GCSLNK/ for Store 0 NL/NS= 100 100 *** GCOMAD: cannot load common GCONSX -I- G3Config: Geant3 with TGeo has been created for Geane. -I- Geane.C: NOPRNT flag set to 1 -I- Geane.C: IERR flags are not printed. If you want to switch them on, please set fErtrio1->noprnt = 0 in Geane.C Energy straggling area parameter from user set to: 0.999 ====================================================== ---- : TransMap.0890 ---- ---- Field type : Trans Map ---- ---- Field map grid : ---- x = 0.000 to 240.0 cm, 61 grid points, dx = 4.000 cm ---- y = -240.0 to 240.0 cm, 241 grid points, dy = 2.000 cm ---- z = 283.0 to 343.0 cm, 41 grid points, dz = 1.500 cm ---- Field centre position: ( 0.000, 0.000, 0.000) cm ---- Field scaling factor: 1.000 ---- ---- Field at origin is ( 0.000, 0.000, 0.000) kG ====================================================== ====================================================== ---- : DipoleMap1.0890 ---- ---- Field type : Dipole Map ---- ---- Field map grid : ---- x = 0.000 to 158.0 cm, 80 grid points, dx = 2.000 cm ---- y = 0.000 to 51.00 cm, 52 grid points, dy = 1.000 cm ---- z = 342.0 to 602.0 cm, 131 grid points, dz = 2.000 cm ---- Field centre position: ( 0.000, 0.000, 0.000) cm ---- Field scaling factor: 1.000 ---- ---- Field at origin is ( 0.000, 0.000, 0.000) kG ====================================================== ====================================================== ---- : DipoleMap2.0890 ---- ---- Field type : Dipole Map ---- ---- Field map grid : ---- x = 0.000 to 170.0 cm, 35 grid points, dx = 5.000 cm ---- y = 0.000 to 60.00 cm, 31 grid points, dy = 2.000 cm ---- z = 560.0 to 660.0 cm, 26 grid points, dz = 4.000 cm ---- Field centre position: ( 0.000, 0.000, 0.000) cm ---- Field scaling factor: 1.000 ---- ---- Field at origin is ( 0.000, 0.000, 0.000) kG ====================================================== ====================================================== ---- : SolenoidMap1 ---- ---- Field type : Soleniod Map ---- ---- Field map grid : ---- x = 0.000 to 231.0 cm, 78 grid points, dx = 3.000 cm ---- y = 0.000 to 231.0 cm, 78 grid points, dy = 3.000 cm ---- z = -172.0 to -40.00 cm, 34 grid points, dz = 4.000 cm ---- Field centre position: ( 0.000, 0.000, 0.000) cm ---- Field scaling factor: 1.000 ---- ---- Field at origin is ( 0.000, 0.000, 0.000) kG ====================================================== ====================================================== ---- : SolenoidMap2 ---- ---- Field type : Soleniod Map ---- ---- Field map grid : ---- x = 0.000 to 231.0 cm, 155 grid points, dx = 1.500 cm ---- y = 0.000 to 231.0 cm, 155 grid points, dy = 1.500 cm ---- z = -40.00 to 180.0 cm, 89 grid points, dz = 2.500 cm ---- Field centre position: ( 0.000, 0.000, 0.000) cm ---- Field scaling factor: 1.000 ---- ---- Field at origin is ( 0.000, 0.000, 20.04) kG ====================================================== ====================================================== ---- : SolenoidMap3 ---- ---- Field type : Soleniod Map ---- ---- Field map grid : ---- x = 0.000 to 231.0 cm, 232 grid points, dx = 1.000 cm ---- y = 0.000 to 231.0 cm, 232 grid points, dy = 1.000 cm ---- z = 180.0 to 248.0 cm, 18 grid points, dz = 4.000 cm ---- Field centre position: ( 0.000, 0.000, 0.000) cm ---- Field scaling factor: 1.000 ---- ---- Field at origin is ( 0.000, 0.000, 0.000) kG ====================================================== ====================================================== ---- : SolenoidMap4 ---- ---- Field type : Soleniod Map ---- ---- Field map grid : ---- x = 0.000 to 240.0 cm, 161 grid points, dx = 1.500 cm ---- y = 0.000 to 240.0 cm, 161 grid points, dy = 1.500 cm ---- z = 247.7 to 283.7 cm, 25 grid points, dz = 1.500 cm ---- Field centre position: ( 0.000, 0.000, 0.000) cm ---- Field scaling factor: 1.000 ---- ---- Field at origin is ( 0.000, 0.000, 0.000) kG ====================================================== Calculating cross section tables, see gphysi.dat for more information Cross section calculation concluded successfully I- FairGeane::FairGeane: Geane is Initialized -W- PndMvdRiemannTrackFinderTask::Init: No Branch Names given with AddHitBranch(TString branchName)! Standard BranchNames taken! -I- PndMvdRiemannTrackFinderTask: Initialisation successfull -I- PndSttMvdTracking: Initialization successfull -I- PndSttMvdTracking: Initialization successfull -I- ------------------- -I- PndSttMvdGemTracking: using branches MVDHitsPixel MVDHitsStrip STTHit GEMHit -I- to change one or more of these use PndSttMvdGemTracking:SetBranchName( TStrings ); the order of TStrings is mvd pixel name, mvd strip name, stt name, gem name -I- ------------------- -I- PndSttMvdGemTracking: Intialisation successfull *** PndRecoKalmanFit::Init MVDHitsStrip array found *** PndRecoKalmanFit::Init MVDHitsPixel array found [INFO ] Branch: PndTpcCluster not found in Tree [INFO ] Branch: PndTpcCluster not found in Tree [INFO ] Branch: SttHelixHit not found in Tree [INFO ] Branch: SttHelixHit not found in Tree *** PndRecoKalmanFit::Init SttHit array found *** PndRecoKalmanFit::Init GEMHit array found [INFO ] Branch: PndDchCylinderHit not found in Tree [INFO ] Branch: PndDchCylinderHit not found in Tree *** PndRecoKalmanFit::Init MdtHit array found ===PndRecoKalmanFit::Init() finished =================================================== [INFO ] The number of entries in chain is 10 *** Break *** floating point exception =========================================================== There was a crash (kSigFloatingException). This is the entire stack trace of all threads: =========================================================== #0 0x00ecd416 in __kernel_vsyscall () #1 0x0753a473 in __waitpid_nocancel () from /lib/libc.so.6 #2 0x074d6753 in do_system () from /lib/libc.so.6 #3 0x00dd382d in system () from /lib/libpthread.so.0 #4 0x004ef70d in TUnixSystem::Exec (this=0x871b470, shellcmd=0xf392610 "/home/dimam/pandaroot/fairsoft/tools/root/etc/gdb-backtrace.sh 3945 1>&2") at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 2036 #5 0x004eff58 in TUnixSystem::StackTrace (this=0x871b470) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 2265 #6 0x004eda61 in TUnixSystem::DispatchSignals (this=0x871b470, sig=kSigFloatingException) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 1162 #7 0x004ebbed in SigHandler (sig=kSigFloatingException) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 362 #8 0x004f32a7 in sighandler (sig=8) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 3552 #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/PndMvdRiemannTrackFinder Task.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 #18 0x02ca4cd8 in G__FairDict_883_0_5 (result7=0xbf87bee8, funcname=0x8735b88 "", libp=0xbf8718a4, hash=0) at /home/dimam/pandaroot/build/base/FairDict.cxx:13383 #19 0x00f5070f in Cint::G__ExceptionWrapper ( funcp=0x2ca4be7 <G__FairDict_883_0_5(G__value*, char const*, G__param*, int)>, result7=0xbf87bee8, funcname=0x8735b88 "", libp=0xbf8718a4, hash=0) at cint/cint/src/Api.cxx:393 #20 0x0101c54b in G__execute_call (result7=0xbf87bee8, libp=0xbf8718a4, ifunc=0x8735b88, ifn=0) at cint/cint/src/newlink.cxx:2406 #21 0x0101cd8a in G__call_cppfunc (result7=0xbf87bee8, libp=0xbf8718a4, ifunc=0x8735b88, ifn=0) at cint/cint/src/newlink.cxx:2610 #22 0x00ff8a15 in G__interpret_func (result7=0xbf87bee8, funcname=0x8729ca0 "Run", libp=0xbf8718a4, hash=309, p_ifunc=0x8735b88, funcmatch=1, memfunc_flag=1) at cint/cint/src/ifunc.cxx:5795 #23 0x00fd4b49 in G__getfunction (item=0x8726f0e "Run(0,nEvents)", known3=0xbf87f3cc, memfunc_flag=1) at cint/cint/src/func.cxx:2665 #24 0x010fa7b9 in G__getstructmem (store_var_type=112, varname=..., membername=0x8726f0e "Run(0,nEvents)", memnamesize=2147483647, tagname=0x8727718 "fRun", known2=0xbf87f3cc, varglobal=0x11bd3a0, objptr=2) at cint/cint/src/var.cxx:6804 #25 0x010eb707 in G__getvariable (item=0x8726f08 "fRun->Run(0,nEvents)", known=0xbf87f3cc, varglobal=0x11bd3a0, varlocal=0x0) at cint/cint/src/var.cxx:5390 #26 0x00fc4cf1 in G__getitem (item=0x8726f08 "fRun->Run(0,nEvents)") at cint/cint/src/expr.cxx:1906 #27 0x00fc2760 in G__getexpr (expression=0x8744d48 "fRun->Run(0,nEvents)") at cint/cint/src/expr.cxx:1488 #28 0x0104c8cb in G__exec_function (statement=..., pc=0xbf881254, piout=0xbf881250, plargestep=0xbf881248, presult=0xbf8811d0) at cint/cint/src/parse.cxx:645 #29 0x0105cfda in G__exec_statement (mparen=0xbf8814b4) at cint/cint/src/parse.cxx:7372 #30 0x00f966f7 in G__exec_tempfile_core ( file=0x8744540 " /home/dimam/pandaroot/pandaroot/macro/run/tdrct/psi3770/./run_reco_stt_e vt.C ", fp=0x0) at cint/cint/src/debug.cxx:265 #31 0x00f98032 in G__exec_tempfile ( file=0x8744540 " /home/dimam/pandaroot/pandaroot/macro/run/tdrct/psi3770/./run_reco_stt_e vt.C ") at cint/cint/src/debug.cxx:813 #32 0x0106b482 in G__process_cmd ( line=0x8acc510 ".x /home/dimam/pandaroot/pandaroot/macro/run/tdrct/psi3770/./run_reco_stt_e vt.C ", prompt=0x871e524 "", more=0x871e51c, err=0xbf882524, rslt=0xbf8824f0) at cint/cint/src/pause.cxx:3170 #33 0x004aab87 in TCint::ProcessLine (this=0x871e4f0, line=0x8acc510 ".x /home/dimam/pandaroot/pandaroot/macro/run/tdrct/psi3770/./run_reco_stt_e vt.C ", error=0x0) at /home/dimam/pandaroot/fairsoft/tools/root/core/meta/src/TCint.cxx:522 #34 0x004ab0fe in TCint::ProcessLineSynch (this=0x871e4f0, line=0x8acc510 ".x /home/dimam/pandaroot/pandaroot/macro/run/tdrct/psi3770/./run_reco_stt_e vt.C ", error=0x0) at /home/dimam/pandaroot/fairsoft/tools/root/core/meta/src/TCint.cxx:601 #35 0x003ff0ee in TApplication::ExecuteFile ( file=0x8ab305b "run_reco_stt_evt.C", error=0x0, keep=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :1035 #36 0x003fe99e in TApplication::ProcessFile (this=0x87e3c18, file=0x8ab305b "run_reco_stt_evt.C", error=0x0, keep=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :911 #37 0x003fe8d3 in TApplication::ProcessLine (this=0x87e3c18, line=0x8ab3058 ".x run_reco_stt_evt.C", sync=false, err=0x0) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :884 #38 0x0011f5ad in TRint::HandleTermInput (this=0x87e3c18) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:561 #39 0x0011d85c in TTermInputHandler::Notify (this=0x8a77730) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:129 #40 0x00120956 in TTermInputHandler::ReadNotify (this=0x8a77730) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:121 #41 0x004eddb1 in TUnixSystem::CheckDescriptors (this=0x871b470) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 1264 #42 0x004ed162 in TUnixSystem::DispatchOneEvent (this=0x871b470, pendingOnly=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 971 #43 0x00462b69 in TSystem::InnerLoop (this=0x871b470) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TSystem.cxx:406 #44 0x0046293b in TSystem::Run (this=0x871b470) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TSystem.cxx:356 #45 0x003ff266 in TApplication::Run (this=0x87e3c18, retrn=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :1051 #46 0x0011edd1 in TRint::Run (this=0x87e3c18, retrn=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:433 #47 0x08048ef3 in main (argc=1, argv=0xbf8854f4) at /home/dimam/pandaroot/fairsoft/tools/root/main/src/rmain.cxx:29 =========================================================== The lines below might hint at the cause of the crash. If they do not help you then please submit a bug report at http://root.cern.ch/bugs. Please post the ENTIRE stack trace from above as an attachment in addition to anything else that might help us fixing this issue. =========================================================== #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/PndMvdRiemannTrackFinder Task.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 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
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
Has the experts checked what is going wrong with the MvdRiemann?
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.
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
Hi, it was crashing exactly at the first event. Now it seems to work. Thanks.
Official code for tracking TDR - PndSttMvdGemTracking problems
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
Re: Official code for tracking TDR - PndSttMvdGemTracking problems
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.
Not yet, I have only found that the only task producing this message is the SttMvdGem one.
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.
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.