GSI Helmholtzzentrum für Schwerionenforschung
Hi all, I checked in correlator tasks for MVD and GEM in tpc/tpcreco. Also, there is a testing macro: macro/run/tdrct/run_reco_tpc.C The scheme is easy: First comes real TPC PR, the fit, then the MVD correlator, another fit, then the correlation with the GEM and the final fit. Please go ahead and try. One observation, though: I still have trouble with GEANE, especially when extrapolating in forward direction into the GEMs (floating point exceptions). I can't do anything about it right now. There is an option in the PR (useGeane()) which is the default in the macro. By disabling it, the track representation will change to RKTrackRep, which shows no such problems, but seems to have inferior material effect calculations. So please try the stability of the channel in question first. Also, I would be helpful if people start using the macro also off the grid in private small runs and share their experience with me. Be sure to update your tpc/tpcreco GenfitTools genfit recotaks macro folders to have the lates reconstruction algorithms in place. Cheers Felix
Hi Felix, I tried TPC reconstruction macro (I adapted it as run_reco_tpc_evt.C in /macro/run/tdtct/eta_c/) run_sim_tpc_evt.C run_digi_tpc_evt.C run_reco_tpc_evt.C and immediately have the following crash from the KalmanTask: Toggle Spoiler ----------------------------------------------------------- GFException thrown with excString: GEANE propagation failed in line: 306 in file: /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/GeaneTrackRep/Geane TrackRep.cxx with fatal flag 0 *** Break *** floating point exception =========================================================== There was a crash (kSigFloatingException). This is the entire stack trace of all threads: =========================================================== #0 0x00de8416 in __kernel_vsyscall () #1 0x044eb473 in __waitpid_nocancel () from /lib/libc.so.6 #2 0x04487753 in do_system () from /lib/libc.so.6 #3 0x0057e82d in system () from /lib/libpthread.so.0 #4 0x007fc70d in TUnixSystem::Exec (this=0x886a470, shellcmd=0xf45d7d8 "/home/dimam/pandaroot/fairsoft/tools/root/etc/gdb-backtrace.sh 4672 1>&2") at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 2036 #5 0x007fcf58 in TUnixSystem::StackTrace (this=0x886a470) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 2265 #6 0x007faa61 in TUnixSystem::DispatchSignals (this=0x886a470, sig=kSigFloatingException) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 1162 #7 0x007f8bed in SigHandler (sig=kSigFloatingException) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 362 #8 0x008002a7 in sighandler (sig=8) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 3552 #9 <signal handler called> #10 0x036b778d in FairGeanePro::Propagate (this=0xe9be450, TStart=0xbfe6cb18, TEnd=0xbfe6c6f0, PDG=321) at /home/dimam/pandaroot/pandaroot/geane/FairGeanePro.cxx:224 #11 0x07a6c747 in GeaneTrackRep::extrapolateToPoint (this=0xf454a08, pos=..., poca=..., dirInPoca=...) at /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/GeaneTrackRep/Geane TrackRep.cxx:304 #12 0x0360e9b1 in GFSpacepointHitPolicy::detPlane (this=0xf453f78, hit= 0xf453d70, rep=0xf454a08) at /home/dimam/pandaroot/pandaroot/genfit/GFSpacepointHitPolicy.cxx:95 #13 0x04ec431d in GFRecoHitIfc<GFSpacepointHitPolicy>::getDetPlane ( this=0xf453d70, rep=0xf454a08) at /home/dimam/pandaroot/pandaroot/genfit/GFRecoHitIfc.h:80 #14 0x036085c3 in GFKalman::processHit (this=0xbfe6e9f0, tr=0xf452140, ihit=10, irep=1, direction=-1) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:269 #15 0x036079fc in GFKalman::fittingPass (this=0xbfe6e9f0, trk=0xf452140, direction=-1) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:168 #16 0x0360737e in GFKalman::processTrack (this=0xbfe6e9f0, trk=0xf452140) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:76 #17 0x073b646f in KalmanTask::Exec (this=0x93ae7c0, opt=0x2bea908 "") at /home/dimam/pandaroot/pandaroot/recotasks/KalmanTask.cxx:264 #18 0x0077ef31 in TTask::ExecuteTasks (this=0x8886658, option=0x2bea908 "") at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:312 #19 0x0077ed47 in TTask::ExecuteTask (this=0x8886658, option=0x2bea908 "") at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:275 #20 0x02b3f557 in FairRunAna::Run (this=0x88865e0, Ev_start=0, Ev_end=10) at /home/dimam/pandaroot/pandaroot/base/FairRunAna.cxx:272 #21 0x02b94a95 in G__FairDict_883_0_5 (result7=0xbfe79e88, funcname=0x8884b78 "", libp=0xbfe6f844, hash=0) at /home/dimam/pandaroot/build/base/FairDict.cxx:13234 #22 0x00e6b70f in Cint::G__ExceptionWrapper ( funcp=0x2b949a4 <G__FairDict_883_0_5(G__value*, char const*, G__param*, int)>, result7=0xbfe79e88, funcname=0x8884b78 "", libp=0xbfe6f844, hash=0) at cint/cint/src/Api.cxx:393 #23 0x00f3754b in G__execute_call (result7=0xbfe79e88, libp=0xbfe6f844, ifunc=0x8884b78, ifn=0) at cint/cint/src/newlink.cxx:2406 #24 0x00f37d8a in G__call_cppfunc (result7=0xbfe79e88, libp=0xbfe6f844, ifunc=0x8884b78, ifn=0) at cint/cint/src/newlink.cxx:2610 #25 0x00f13a15 in G__interpret_func (result7=0xbfe79e88, funcname=0x8878ca0 "Run", libp=0xbfe6f844, hash=309, p_ifunc=0x8884b78, funcmatch=1, memfunc_flag=1) at cint/cint/src/ifunc.cxx:5795 #26 0x00eefb49 in G__getfunction (item=0x8875f0e "Run(0,nEvents)", known3=0xbfe7d36c, memfunc_flag=1) at cint/cint/src/func.cxx:2665 #27 0x010157b9 in G__getstructmem (store_var_type=112, varname=..., membername=0x8875f0e "Run(0,nEvents)", memnamesize=2147483647, tagname=0x8876718 "fRun", known2=0xbfe7d36c, varglobal=0x10d83a0, objptr=2) at cint/cint/src/var.cxx:6804 #28 0x01006707 in G__getvariable (item=0x8875f08 "fRun->Run(0,nEvents)", known=0xbfe7d36c, varglobal=0x10d83a0, varlocal=0x0) at cint/cint/src/var.cxx:5390 #29 0x00edfcf1 in G__getitem (item=0x8875f08 "fRun->Run(0,nEvents)") at cint/cint/src/expr.cxx:1906 #30 0x00edd760 in G__getexpr (expression=0x8893d48 "fRun->Run(0,nEvents)") at cint/cint/src/expr.cxx:1488 #31 0x00f678cb in G__exec_function (statement=..., pc=0xbfe7f1f4, piout=0xbfe7f1f0, plargestep=0xbfe7f1e8, presult=0xbfe7f170) at cint/cint/src/parse.cxx:645 #32 0x00f77fda in G__exec_statement (mparen=0xbfe7f454) at cint/cint/src/parse.cxx:7372 #33 0x00eb16f7 in G__exec_tempfile_core ( file=0x8893540 " /home/dimam/pandaroot/pandaroot/macro/run/tdrct/eta_c/./run_reco_tpc_evt .C ", fp=0x0) at cint/cint/src/debug.cxx:265 #34 0x00eb3032 in G__exec_tempfile ( file=0x8893540 " /home/dimam/pandaroot/pandaroot/macro/run/tdrct/eta_c/./run_reco_tpc_evt .C ") at cint/cint/src/debug.cxx:813 #35 0x00f86482 in G__process_cmd ( line=0x8c1b938 ".x /home/dimam/pandaroot/pandaroot/macro/run/tdrct/eta_c/./run_reco_tpc_evt .C ", prompt=0x886d524 "", more=0x886d51c, err=0xbfe804c4, rslt=0xbfe80490) at cint/cint/src/pause.cxx:3170 #36 0x007b7b87 in TCint::ProcessLine (this=0x886d4f0, line=0x8c1b938 ".x /home/dimam/pandaroot/pandaroot/macro/run/tdrct/eta_c/./run_reco_tpc_evt .C ", error=0x0) at /home/dimam/pandaroot/fairsoft/tools/root/core/meta/src/TCint.cxx:522 #37 0x007b80fe in TCint::ProcessLineSynch (this=0x886d4f0, line=0x8c1b938 ".x /home/dimam/pandaroot/pandaroot/macro/run/tdrct/eta_c/./run_reco_tpc_evt .C ", error=0x0) at /home/dimam/pandaroot/fairsoft/tools/root/core/meta/src/TCint.cxx:601 #38 0x0070c0ee in TApplication::ExecuteFile ( file=0x8c0d2e3 "run_reco_tpc_evt.C", error=0x0, keep=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :1035 #39 0x0070b99e in TApplication::ProcessFile (this=0x8932c18, file=0x8c0d2e3 "run_reco_tpc_evt.C", error=0x0, keep=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :911 #40 0x0070b8d3 in TApplication::ProcessLine (this=0x8932c18, line=0x8c0d2e0 ".x run_reco_tpc_evt.C", sync=false, err=0x0) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :884 #41 0x0011f5ad in TRint::HandleTermInput (this=0x8932c18) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:561 #42 0x0011d85c in TTermInputHandler::Notify (this=0x8bc6730) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:129 #43 0x00120956 in TTermInputHandler::ReadNotify (this=0x8bc6730) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:121 #44 0x007fadb1 in TUnixSystem::CheckDescriptors (this=0x886a470) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 1264 #45 0x007fa162 in TUnixSystem::DispatchOneEvent (this=0x886a470, pendingOnly=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/unix/src/TUnixSystem.cxx: 971 #46 0x0076fb69 in TSystem::InnerLoop (this=0x886a470) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TSystem.cxx:406 #47 0x0076f93b in TSystem::Run (this=0x886a470) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TSystem.cxx:356 #48 0x0070c266 in TApplication::Run (this=0x8932c18, retrn=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TApplication.cxx :1051 #49 0x0011edd1 in TRint::Run (this=0x8932c18, retrn=false) at /home/dimam/pandaroot/fairsoft/tools/root/core/rint/src/TRint.cxx:433 #50 0x08048ef3 in main (argc=1, argv=0xbfe83494) 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 0x036b778d in FairGeanePro::Propagate (this=0xe9be450, TStart=0xbfe6cb18, TEnd=0xbfe6c6f0, PDG=321) at /home/dimam/pandaroot/pandaroot/geane/FairGeanePro.cxx:224 #11 0x07a6c747 in GeaneTrackRep::extrapolateToPoint (this=0xf454a08, pos=..., poca=..., dirInPoca=...) at /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/GeaneTrackRep/Geane TrackRep.cxx:304 #12 0x0360e9b1 in GFSpacepointHitPolicy::detPlane (this=0xf453f78, hit= 0xf453d70, rep=0xf454a08) at /home/dimam/pandaroot/pandaroot/genfit/GFSpacepointHitPolicy.cxx:95 #13 0x04ec431d in GFRecoHitIfc<GFSpacepointHitPolicy>::getDetPlane ( this=0xf453d70, rep=0xf454a08) at /home/dimam/pandaroot/pandaroot/genfit/GFRecoHitIfc.h:80 #14 0x036085c3 in GFKalman::processHit (this=0xbfe6e9f0, tr=0xf452140, ihit=10, irep=1, direction=-1) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:269 #15 0x036079fc in GFKalman::fittingPass (this=0xbfe6e9f0, trk=0xf452140, direction=-1) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:168 #16 0x0360737e in GFKalman::processTrack (this=0xbfe6e9f0, trk=0xf452140) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:76 #17 0x073b646f in KalmanTask::Exec (this=0x93ae7c0, opt=0x2bea908 "") at /home/dimam/pandaroot/pandaroot/recotasks/KalmanTask.cxx:264 #18 0x0077ef31 in TTask::ExecuteTasks (this=0x8886658, option=0x2bea908 "") at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:312 #19 0x0077ed47 in TTask::ExecuteTask (this=0x8886658, option=0x2bea908 "") at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:275 #20 0x02b3f557 in FairRunAna::Run (this=0x88865e0, Ev_start=0, Ev_end=10) at /home/dimam/pandaroot/pandaroot/base/FairRunAna.cxx:272 =========================================================== Root > ------------------------------------------------------------- From the log it looks like it's the first event and third call of KalmanTask, i.e. after PndTpcGEMCorrelatorTask. And I have to admit that numerous messages from the floating point exceptions ---------------------------------------------------- GFException thrown with excString: GEANE propagation failed in line: 306 in file: /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/GeaneTrackRep/Geane TrackRep.cxx with fatal flag 0 ABORT ---------------------------------------------------- seriously complicates reading the log, but Felix mentioned them already. Dima
Hi, I have just run the new macro/run/tdrct/run_tpc_reco.C macro. First I have run 50 evtgen events, after digitization, and after reco: root -l run_sim_tpc_evt.C"(50)" root -l run_digi_tpc_evt.C root -l run_reco_tpc.C (of course I have edited the input file names in the reco). At the end of the first event I have the following crash: GFAbsTrackRep::chi^2 1543. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ starting track3 GFException thrown with excString: GFRecoHitFactory: no hitProducer for this detID available in line: 61 in file: /home/spataro/may11/may11/genfit/GFRecoHitFactory.cxx with fatal flag 0 GFException Info Output =========================== Numbers Label String: detID --------------------------- Numbers: 24.00 =========================== Error: Symbol #include is not defined in current scope run_reco_tpc.C:141: Error: Symbol exception is not defined in current scope run_reco_tpc.C:141: Syntax Error: #include <exception> run_reco_tpc.C:141: Error: Symbol G__exception is not defined in current scope run_reco_tpc.C:141: Error: type G__exception not defined FILE:/home/spataro/may11/may11/macro/run/tdrct/./run_reco_tpc.C LINE:141 *** Interpreter error recovered *** root [1] If I comment out the last kalmantask I have no crash anymore (at least with 50 events). Could you please check? I suppose there is some not caught exception in the KalmanTask. I have several comments about the new reco macro: Ca we move the tpc clusterization to the digi macro, or remove it in the digi? At present we are running the same code, even if with different parameters, twice I suppose you do not need the mvdriemann code for the tpc+mvd tracking, unlike the stt case. Isn't it? (just to be sure) You are running tpc tracking, and after kalman, then tpc+mvd, and kalman, tpc+mvd+gem, and kalman. Would it be much faster to run tpc tpc+mvd and tpc+mvd+gem only with the prefit values, and to run only a final kalman at the end? This would save a lot of time, a lot of crashes and memory usage, and I suppose in the prefit phase we do not need to "kalmanize" the tracks but only at the end for the fina parameters Which particle hypothesis are you using for the kalman? Is there a way to reduce all those messages? They make the log output file large I would strongly suggest to use the GenfitTools/recotask/PndRecoKalmanTask-Fit (as I have already told to Sebastian when he came back into the business, almost one month ago), because it is in the standard way and return directly a PndTrack object from another PndTrack object. Probably KalmanTask and PndRecoKalmanTask/Fit should just be compared, they are doing the same things but with different output. The main problem is that, if we run the KalmanTask, we have also to write a new task converting the GFTrack into PndTrack, while this job is already done in the PndRecoKalmanFit code. The PndTrack object is the starting point of the correlator to produce our TCandidate, without PndTrack users cannot run analysis Of course I will help for the coding, at least for the common parts.
Hi Dima, this is one of the dreaded GEANE floating point exceptions Imentrioned. I am trying to get to the bottom of this with Lias help today. Until then I recommend turning off GEANE in the macro as I explained. Cheers Felix
Hi Stefano, do you have the latest version of the KalmanTask? It looks like you don't and there is one of the RecoHitProducers not properly defined. To your questions: Quote: Ca we move the tpc clusterization to the digi macro, or remove it in the digi? At present we are running the same code, even if with different parameters, twice I removed the clustering from the reco macro. Quote: I suppose you do not need the mvdriemann code for the tpc+mvd tracking, unlike the stt case. Isn't it? (just to be sure) You are right, I don't. Quote: You are running tpc tracking, and after kalman, then tpc+mvd, and kalman, tpc+mvd+gem, and kalman. Would it be much faster to run tpc tpc+mvd and tpc+mvd+gem only with the prefit values, and to run only a final kalman at the end? This would save a lot of time, a lot of crashes and memory usage, and I suppose in the prefit phase we do not need to "kalmanize" the tracks but only at the end for the fina parameters What you describe was my first approach. However, using the MVD hits after TPC+MVD correlation in a fit gives better results for the (possibly very long) extrapolation into the GEMs. I would keep it that way. I agree that it is slow, but it is the best I have right now. The crashes are completely isoloated to GEANE extrapolations into the GEMs as far as I can tell right now... I am working on it, as I said. Quote: Which particle hypothesis are you using for the kalman? Is there a way to reduce all those messages? They make the log output file large The particle hypothesis is obtained from MC information isndie the PndTpcRiemannTrackingTask. I can build in a setter if you want to have manual control during the reco. Quote: I would strongly suggest to use the GenfitTools/recotask/PndRecoKalmanTask-Fit (as I have already told to Sebastian when he came back into the business, almost one month ago), because it is in the standard way and return directly a PndTrack object from another PndTrack object. Probably KalmanTask and PndRecoKalmanTask/Fit should just be compared, they are doing the same things but with different output. The main problem is that, if we run the KalmanTask, we have also to write a new task converting the GFTrack into PndTrack, while this job is already done in the PndRecoKalmanFit code. The PndTrack object is the starting point of the correlator to produce our TCandidate, without PndTrack users cannot run analysis I can take a look at this after I have fixed all the other, more urgent problem. I would be very grateful if you could have a lokk at this. Probably the exchange would be a very technical task, but rather easy. Quote: Of course I will help for the coding, at least for the common parts. You shouldn't have said that, see my answer above
Hi Felix, turning off GEANE, i.e. commenting the line tpcSPR->useGeane(); // use RKTrackrep and GeaneTrackrep I have the same error which Stefano reported: --------------------------------------------------- *** Number of clusters in track: 10 *** starting fit Calling processTrack starting track8 GFException thrown with excString: GFRecoHitFactory: no hitProducer for this detID available in line: 61 in file: /home/dimam/pandaroot/pandaroot/genfit/GFRecoHitFactory.cxx with fatal flag 0 GFException Info Output =========================== Numbers Label String: detID --------------------------- Numbers: 24.00 =========================== Error: Symbol #include is not defined in current scope run_reco_tpc_evt.C:145: Error: Symbol exception is not defined in current scope run_reco_tpc_evt.C:145: Syntax Error: #include <exception> run_reco_tpc_evt.C:145: Error: Symbol G__exception is not defined in current scope run_reco_tpc_evt.C:145: Error: type G__exception not defined FILE:/home/dimam/pandaroot/pandaroot/macro/run/tdrct/eta_c/./run_reco_tp c_evt.C LINE:145 *** Interpreter error recovered *** --------------------------------------------------- Dima
Hi Dima & Stefano, can you please go to the GenfitTools/trackrep folder and type svn propget svn:externals What do you see ? Is there still a fixed revision for the RKTrackRep? If so, please remove it by doing svn propget svn:externals > tempfile editing tempFile, e.g. removing the version statement in the RKTrackRep line svn propset svn:externals -F tempfile . and then doing another svn up there? If this is the problem then we will have to update the externals definitions... Sorry for the inconvience. Cheers Felix
Hi Felix, svn propget svn:externals gives for me LSLtrackRep -r216 https://genfit.svn.sourceforge.net/svnroot/genfit/LSLtrackRep GeaneTrackRep2 -r216 https://genfit.svn.sourceforge.net/svnroot/genfit/GeaneTrackRep2 RKTrackRep -r313 https://genfit.svn.sourceforge.net/svnroot/genfit/RKTrackRep I changed as you said version statement in the RKTrackRep line. After svn update I have the following problem with compilation ----------------------------------------- Scanning dependencies of target trackrep [ 79%] Building CXX object GenfitTools/trackrep/CMakeFiles/trackrep.dir/RKTrackRep/RKTrackRep.cxx.o /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/RKTrackRep/RKTrackRep.cxx:38:30: error: GFMaterialEffects.h: No such file or directory /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/RKTrackRep/RKTrackRep.cxx: In member function ‘bool RKTrackRep::RKutta(const GFDetPlane&, double*, double&, std::vector<TVector3, std::allocator<TVector3> >&, std::vector<double, std::allocator<double> >&, const double&, bool) const’: /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/RKTrackRep/RKTrackRep.cxx:697: error: ‘GFMaterialEffects’ has not been declared /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/RKTrackRep/RKTrackRep.cxx: In member function ‘double RKTrackRep::Extrap(const GFDetPlane&, TMatrixT<double>*, TMatrixT<double>*) const’: /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/RKTrackRep/RKTrackRep.cxx:1059: error: ‘GFMaterialEffects’ has not been declared make[2]: *** [GenfitTools/trackrep/CMakeFiles/trackrep.dir/RKTrackRep/RKTrackRep.cxx.o] Error 1 make[1]: *** [GenfitTools/trackrep/CMakeFiles/trackrep.dir/all] Error 2 make: *** [all] Error 2 I suspect that the version for genfit itself should also be changed from genfit -r 313 https://genfit.svn.sourceforge.net/svnroot/genfit/core And just for completeness, should the version number for GeaneTrackRep2 stay fixed or should it be removed also? Dima
Hi Dima, yes, please try to go to the head revision of the genfit core. We need to solve this urgently. Keep me updated please Felix
Hi Felix, after updating to the head revision of the genfit core I finally managed to run tpc reconstruction macro for 10 events. But I suppose that genfit version, including RKTrackRep should be updated centrally in svn repository. Dima
Yes, I will communicate this to the genfit developers. We have to find some solution together with Stefano & Co. Please keep me up to date concerning the results Cheers Felix
Hi, Felix Boehmer wrote on Thu, 16 June 2011 14:52 Hi Stefano, do you have the latest version of the KalmanTask? It looks like you don't and there is one of the RecoHitProducers not properly defined. It is the 12357, but I have seen you have done a modification at 14:30 which I had not. I will run again. Quote: To your questions: Quote: Ca we move the tpc clusterization to the digi macro, or remove it in the digi? At present we are running the same code, even if with different parameters, twice I removed the clustering from the reco macro. This means that the cluster code in the run_digi_tpc_*.C is fine, isn't it? I have seen it was a bit different from the one in the reco macro. In the digi: PndTpcClusterFinderTask* tpcCF = new PndTpcClusterFinderTask(); tpcCF->SetDigiPersistence(); // keep Digis refs in clusters tpcCF->SetPersistence(); // keep Clusters tpcCF->timeslice(10); //in samples tpcCF->SetErrorPars(600,300); tpcCF->SetSimpleClustering(); // use PndTpcClusterFinderSimple fRun->AddTask(tpcCF); In the reco: PndTpcClusterFinderTask* tpcCF = new PndTpcClusterFinderTask(); //tpcCF->SetDigiPersistence(); // keep reference to digis in clusters tpcCF->SetPersistence(); // keep Clusters tpcCF->timeslice(4); //in samples tpcCF->SetThreshold(1); tpcCF->SetSingleDigiClusterAmpCut(0.); tpcCF->SetClusterAmpCut(0.); // cut on mean digi amplitude tpcCF->SetErrorPars(600.,400.); tpcCF->SetSimpleClustering(); // use PndTpcClusterFinderSimple fRun->AddTask(tpcCF); Which of them? Quote: What you describe was my first approach. However, using the MVD hits after TPC+MVD correlation in a fit gives better results for the (possibly very long) extrapolation into the GEMs. I would keep it that way. I agree that it is slow, but it is the best I have right now. The crashes are completely isoloated to GEANE extrapolations into the GEMs as far as I can tell right now... I am working on it, as I said. So maybe we can take out the first kalman. I am not scared by code crashes or geane crashed, these we can fix, it is matter of track cleaning, taking out tracks which could give errors in arithmetical calculations. I am more scared by crashes connected to memory usage, geane seems to eat a bit of memory and running it three times in the same macro... let's cross the fingers! Quote: Quote: Which particle hypothesis are you using for the kalman? Is there a way to reduce all those messages? They make the log output file large The particle hypothesis is obtained from MC information isndie the PndTpcRiemannTrackingTask. I can build in a setter if you want to have manual control during the reco. Just to know, in stt case we are using the fixed particle hypothesis (muon as default). Probably the mc method should be also implemented in the RecoKalmanTask version. But a flag, also for the verbose of the kalman, would be great (I suppose with lower priority). Quote: I can take a look at this after I have fixed all the other, more urgent problem. I would be very grateful if you could have a lokk at this. Probably the exchange would be a very technical task, but rather easy. Ok, I have also some objections about the enum fDetectorId, because ti breaks a bit also the pid and analysis part, but first let's see what is happening with the "normal" version.
Hi there, nothing speaks against using the newest revision of core and RKTrackRep (330). I was surprised to read that 313 wont do it. I dont know exactly what fix is doing the job, but if 330 works that is great. Cheers, Christian
Hi Christian, nice that you participate. What would be the latest genfit core revision we could switch to? Cheers Felix
Hi, I simplified and rearranged the material interface, and that change is in version 316. So using a post 316 RKTrackRep with a pre 316 core will not work. We are still investigating in floating point exceptions in the GeaneTrackRep, so for the time being it might be the best to use the head revisions of RK and Geane Trackrep. The latest revision of the core is 316, since then, the core has not changed. cheers, Johannes
Hi, I have run 50 events doing an svn update, and now I have no crashes - standard geanetrackrep (ok, I have to test more events). Still I have not understood which is the "final" object storing the track parameters after tpc+mvd+gem. I can see a TrackPostFitComplete, but if I have understood well that is only a PndTrackCand. Where are momentum and track parameters stored?
Hi Stefano, TrackPostFitComplete is in fact a GFTrack. You can get all the information out of this object (e.g. the trackrep inside), for example by calling getMom(). Regards Felix
Hi all, in the stacktrace the line 224 of FairGeanePro.cxx is the origin of the crash... in that line I see (I have the latest revision of trunk updated): ein[i]=fCov[i]; where ein is the vector of the covariance matrix which will be used in GEANE and fCov[i] is the covariance matrix of the track param given in input. Are all the elements of the covariance matrix filled and with reasonable values (I mean, no 1e-234 or something like this)... Cheers, Lia.
Hi Lia, thank you for helping. Any idea what might be the reason? We're looking into it. Bye Felix
Dear Lia, I just checked in an new version of GeaneTrackRep. There were some lines in the code where x and y could both become very small. Could you please check if it solves the problem? cheers, Johannes
Hi Johannes, from my side it was just an hypothesis, I didn' t run the code I just read the backtrace Dima posted and looked in the geane interface, so maybe he can tell you if the crash disappeares with your last changes... Cheers, Lia.
Hi, Concerning the revisions of GenfitTools/trackrep .... what is the punchline now? Shall I change the revision in trunk so that all the users can enjoy that? If so, which revision numbers to use for the various folders? Greets, Johan.
Hi all, first comment is to Felix. And it is related to removing PndTpcClusterFinderTask from reco macro. Actually after this task is removed for me tpc reco macro crashes with Toggle Spoiler I- FairGeane::FairGeane: Geane is Initialized PndTpcGas: Reading data file: NEON-90_CO2-10_B2_PRES1013.asc Fatal in <PndTpcGas::PndTpcGas>: Input File is not found aborting #0 0x00007f8acbff19e5 in waitpid () from /lib/libc.so.6 #1 0x00007f8acbf91e11 in do_system () from /lib/libc.so.6 #2 0x00007f8ace0d5dc6 in TUnixSystem::StackTrace () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #3 0x00007f8ace00129b in DefaultErrorHandler () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #4 0x00007f8ace000c07 in ErrorHandler () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #5 0x00007f8ace000d33 in Fatal () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #6 0x00007f8abec5d691 in PndTpcGas (this=0x363f240, Filename= 0x7fffbae64e40, E=400) at /d/panda02/dmelnych/pandaroot/pandaroot/tpc/PndTpcGas.cxx:53 #7 0x00007f8abec75c73 in PndTpcDigiMapper (this=0x38a9510, autoinit=true) at /d/panda02/dmelnych/pandaroot/pandaroot/tpc/PndTpcDigiMapper.cxx:19 #8 0x00007f8abec81b40 in PndTpcDigiMapper::getInstance (autoinit=true) at /d/panda02/dmelnych/pandaroot/pandaroot/tpc/PndTpcDigiMapper.h:63 #9 0x00007f8abe08d074 in PndTpcRiemannTrackingTask::Init (this=0x2917110) at /d/panda02/dmelnych/pandaroot/pandaroot/tpc/tpcreco/PndTpcRiemannTrackin gTask.cxx:219 #10 0x00007f8ac29abb8f in FairTask::InitTask (this=0x2917110) at /d/panda02/dmelnych/pandaroot/pandaroot/base/FairTask.cxx:48 #11 0x00007f8ac29abc26 in FairTask::InitTasks (this=0x1803410) at /d/panda02/dmelnych/pandaroot/pandaroot/base/FairTask.cxx:120 #12 0x00007f8ac29abbf0 in FairTask::InitTask (this=0x1803410) at /d/panda02/dmelnych/pandaroot/pandaroot/base/FairTask.cxx:53 #13 0x00007f8ac29a5cc0 in FairRunAna::Init (this=0x1803340) at /d/panda02/dmelnych/pandaroot/pandaroot/base/FairRunAna.cxx:208 #14 0x00007f8ac29f500d in G__FairDict_883_0_4 (result7=0x7fffbae70ce0, funcname=0x17fdb40 "", libp=0x7fffbae662d0, hash=0) at /d/panda02/dmelnych/pandaroot/build_lenny64/base/FairDict.cxx:13225 #15 0x00007f8acd518644 in Cint::G__ExceptionWrapper () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #16 0x00007f8acd5ca560 in G__execute_call () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #17 0x00007f8acd5cb369 in G__call_cppfunc () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #18 0x00007f8acd5a6645 in G__interpret_func () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #19 0x00007f8acd593e38 in G__getfunction () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #20 0x00007f8acd68663f in G__getstructmem () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #21 0x00007f8acd67fa1e in G__getvariable () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #22 0x00007f8acd566f2f in G__getitem () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #23 0x00007f8acd56af5c in G__getexpr () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #24 0x00007f8acd5f7bc4 in G__exec_statement () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #25 0x00007f8acd552f16 in G__exec_tempfile_core () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #26 0x00007f8acd5531db in G__exec_tempfile () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #27 0x00007f8acd60b099 in G__process_cmd () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCint.so.5.29 #28 0x00007f8ace092315 in TCint::ProcessLine () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #29 0x00007f8ace091763 in TCint::ProcessLineSynch () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #30 0x00007f8acdfe6f70 in TApplication::ExecuteFile () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #31 0x00007f8acdfe4ab8 in TApplication::ProcessLine () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #32 0x00007f8acce7f545 in TRint::HandleTermInput () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libRint.so.5.29 #33 0x00007f8ace0d3804 in TUnixSystem::CheckDescriptors () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #34 0x00007f8ace0d3e21 in TUnixSystem::DispatchOneEvent () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #35 0x00007f8ace04af66 in TSystem::InnerLoop () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #36 0x00007f8ace04d20c in TSystem::Run () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #37 0x00007f8acdfe278f in TApplication::Run () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libCore.so.5.29 #38 0x00007f8acce81554 in TRint::Run () from /misc/cbmsoft/Lenny64/may11/fairsoft/tools/root/lib/libRint.so.5.29 #39 0x000000000040117d in main () So the problem is that in PndTpcRiemannTrackingTask instance of PndTpcDigiMapper is called but it is initialised in PndTpcClusterFinderTask. So PndTpcClusterFinderTask should be left in tpc reconstruction macro or PndTpcDigiMapper in PndTpcRiemannTrackingTask should be properly initialised. But besides this after updating to the latest GeaneTrackRep I run tpc reconstruction with GeaneTrackRep without crashes. However I still run the check with higher number of events. Dima
Hi all, I run tpc reco with higher number of events, i.e. 2000 and unfortunately everything stops with an error, however from the log it's difficult to say after which event, but after 9 hours of calculations: ... processing TPC track no. 102 ======= TempCand from found GEM hits has size 0 ======= ... processing TPC track no. 103 ======= TempCand from found GEM hits has size 0 ======= ... processing TPC track no. 104 ======= TempCand from found GEM hits has size 0 ======= Error: Symbol #include is not defined in current scope run_reco_tpc_evt.C:145: Error: Symbol exception is not defined in current scope run_reco_tpc_evt.C:145: Syntax Error: #include <exception> run_reco_tpc_evt.C:145: Error: Symbol G__exception is not defined in current scope run_reco_tpc_evt.C:145: Error: type G__exception not defined FILE:/d/panda02/dmelnych/pandaroot/pandaroot/macro/run/tdrct/eta_c/lenny64/101/./run_reco_tpc_evt.C LINE:145 *** Interpreter error recovered *** Error in ERTRAK : No prediction. Tracking stops now Error in ERTRAK : No prediction. Tracking stops now Error in ERTRAK : No prediction. Tracking stops now Error in ERTRAK : No prediction. Tracking stops now Error in ERTRAK : No prediction. Tracking stops now But in addition running on different computer my previous error still persists, i.e. =========================================================== #10 0x0392f78d in FairGeanePro::Propagate (this=0xeba1948, TStart=0xbfdf3548, TEnd=0xbfdf3120, PDG=321) at /home/dimam/pandaroot/pandaroot/geane/FairGeanePro.cxx:224 #11 0x03b645fb in GeaneTrackRep::extrapolateToPoint (this=0xf639c78, pos=..., poca=..., dirInPoca=...) at /home/dimam/pandaroot/pandaroot/GenfitTools/trackrep/GeaneTrackRep/GeaneTrackRep.cxx:305 #12 0x03ac25f9 in GFSpacepointHitPolicy::detPlane (this=0xf6391e8, hit= 0xf638fe0, rep=0xf639c78) at /home/dimam/pandaroot/pandaroot/genfit/GFSpacepointHitPolicy.cxx:95 #13 0x05b6b31d in GFRecoHitIfc<GFSpacepointHitPolicy>::getDetPlane ( this=0xf638fe0, rep=0xf639c78) at /home/dimam/pandaroot/pandaroot/genfit/GFRecoHitIfc.h:80 #14 0x03abc68d in GFKalman::processHit (this=0xbfdf5420, tr=0xf6373b0, ihit=10, irep=1, direction=-1) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:267 #15 0x03abbbbc in GFKalman::fittingPass (this=0xbfdf5420, trk=0xf6373b0, direction=-1) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:169 #16 0x03abb53e in GFKalman::processTrack (this=0xbfdf5420, trk=0xf6373b0) at /home/dimam/pandaroot/pandaroot/genfit/GFKalman.cxx:77 #17 0x078fb83d in KalmanTask::Exec (this=0x9552558, opt=0x323a908 "") at /home/dimam/pandaroot/pandaroot/recotasks/KalmanTask.cxx:264 #18 0x00833f31 in TTask::ExecuteTasks (this=0x8a72658, option=0x323a908 "") at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:312 #19 0x00833d47 in TTask::ExecuteTask (this=0x8a72658, option=0x323a908 "") at /home/dimam/pandaroot/fairsoft/tools/root/core/base/src/TTask.cxx:275 #20 0x0318f557 in FairRunAna::Run (this=0x8a725e0, Ev_start=0, Ev_end=10) at /home/dimam/pandaroot/pandaroot/base/FairRunAna.cxx:272 =========================================================== Dima
Hi Dima, it's an exception inside the GEANE's extrapolation. I'm trying to fix it. Keep on testing, please. Have you used RK also for some tests? Cheers Felix
Hi Felix, I managed to generate a number of events in RKTrackRep and the actual test would be to generate invariant mass plots. But to do it in standard way using rho package TCandidates are needed, which are generated by PndPidCorrelator from PndTrack. And as Stefano has written to have PndTrack there two options: to use PndRecoKalmanTask instead of KalmanTask or to create separate task to convert TClonesArray of GFTrack to TClonesArray of PndTrack. Second option is rather easy using using PndGenfitAdapters.cxx but I understood that Stefano was in favour of first option. And here I want to ask Stefano for comment if he tried to do something in this direction already. And if he does not foresee to have something ready today I consider to write by myself a Task for GFTrack->PndTrack conversion. Dima
Hi, there are mainly two problems: a) the code is using the obsolete fDetectorId style, which is not compatible with the PndRecokalmanTask and neither with PndPidCorrelator b) the code is producing gftracks and not pndtrack For a) I can try to fix it writing a PndDetectorListFake, where the enum becomes a series of constants, i.e.: const Int_t kTpcCluster = FairRootManager::Instance()->GetBranchId("PndTpcCluster") In this way, all the tpc class headers should use PndDetectorListFake instead of PndDetectorList. Of course this is only a momentary solution and after the TDR activities it should be fixed in the tracking code itself. For b) a task as adapter would be great. I cannot do it because I have to fix many other things on the grid side, but if you want to spend some time... it could be placed in GenfitTools/recotasks. The scheme should be already present in PndRecoKalmanTask/Fit and it is just a matter of copy and paste (hopefully). But after you will have the problem with the mvd part of the PndPidCorrelator. To avoid it, you should switch off mvd pid: corr->SetMvdMode(0) using the last version of the PndPidCorrelator.
Hi Stefano, I had originally already implemented the PndTracks and PndTrackCands in the ideal TPC PR about a year ago. We didn't include it in the RiemannPR because we keep having problems with the FairLinks when creating these objects. As you know, we can't use them for the TPC code because of memory issues. If you can fiddle together an adapter I would be most grateful, but right now our focus is on finding out what goes wrong with GEANE. Cheers Felix
Hi all, I tried to implement task for GFTrack to PndTrack conversion using adapters from GenfitTools/adapters/PndGenfitAdapters.cxx and trying to run it in tpc reco task I observed that GenfitTrack2PndTrack adapter support only GeaneTrackRep. So as a next step I tried to edit PndGenfitAdapters.cxx to support also RKTrackRep. So from the compilation and run-time point of view everything work. I.e. I have a TClonesArray of PndTrack. The class is called PndGFTrackToPndTrackConvertorTask and I assume that it should be called in tpc reconstruction macro after last KalmanTask. PndGFTrackToPndTrackConvertorTask* converter =new PndGFTrackToPndTrackConvertorTask(); converter->SetTrackInBranchName("TrackPostFitComplete"); converter->SetTrackOutBranchName("PndTrackPostFitComplete"); fRun->AddTask(converter); I tried to check in the code but I do not have write access to GenfitTools directory. I attached the files (PndGFTrackToPndTrackConvertorTask.cxx, PndGFTrackToPndTrackConvertorTask.h) to be placed /GenfitTools/recotasks/ with corrected CMakeList.txt and RecoTasksLinkDef.h and corrected adapter PndGenfitAdapters.cxx to be placed to /GenfitTools/adapters/. In addition in /GenfitTools/adapters/CMakeList.txt there is an error It should be instead of ${CMAKE_SOURCE_DIR}/GenfitTools/trackrep/RKtrackRep the following ${CMAKE_SOURCE_DIR}/GenfitTools/trackrep/RKTrackRep i.e. capital "T" instead of small one. So could some body check it in, Stefano or Felix? Now I will try to run higher statistics to see if the results are reasonable, but it will take some time. Dima
Done, it compiles, I don't know if it works also Test and modifications to macros are welcome, I had no time to try.
Hi Stefano, Could you may be also update revision of genfit and RKTrackRep to 330 if you have write access to have this point also settled. I just updated from the trunk and had to return it by hand from 313 to 330 again in my local installation to resolve the conflict. Dima
No, this I cannot do it. Only Mohammad and Florian, I suppose.
Hi, Stefano and Johan could also do it! any way I set it to 330. regards, Mohammad
The correct sentence was "I have no idea how to do it":)