Lia Lavezzi and Alberto Rotondi

PANDA meeting, Vienna 1-5 september2Tracking vs MC for newcomers MC= at each step the trajectory is sampled as a random value Result:hystograms of many particles Tracking= at each step the trajectory is calculated as a mean value with an associate error Result: mean and error for one “particle” track follower track following

GEANE is a tracking program: it treats the track as a 5-dimensional object and finds its points as mean values with errors Mean values depends on magnetic field, ionization energy loss, radiation energy loss Errors depends on energy loss, multiple scattering and on the previous track history Tracking is necessary for global fitting Tracking is necessary for global fitting (Kalman filter and GaussianSumFilter) (Kalman filter and GaussianSumFilter)

Check on the tracking of any charged particle and of neutral particles In the helix parabola contructors sometimes the transformation is not possible and it fails: a comment is needed to explain why (it is due to the SD/SC transformation failure) PropagateToLength(0) must be fixed (peraphs in FORTRAN) to be able to propagate to track length = 0 (i.e. don’ t move) Check the option'O’ ( = only); it should the mean values witout the errors. If it is so, a function to use it must be added to the interface Add the covariance matrix in MARS (6X6) in FairTrackParH Check the tracking along the z axis Fix bug to prevent crash (e.g. in xmm55 ) BUG FIXES AND THINGS TO BE ADDED TO DO LIST – EVO 07/10/2009 IT WAS DECIDED THIS IS NOT NECESSARY DONE In the new CERN release and in the FAIR Root interface New GEANE PATCH

PATCH SENT TO CERN (xmm55 crash & Co.) A patch has been sent to CERN and the corrections have been included in rev. 252 of geant3 The patch contains the previous red points and the following corrections: 1. fix for crash in electron tracking - erland.F 2. fix for missing virtual detector planes - ertrch.F A patch has been sent to CERN and the corrections have been included in rev. 252 of geant3 The patch contains the previous red points and the following corrections: 1. fix for crash in electron tracking - erland.F 2. fix for missing virtual detector planes - ertrch.F

PATCH SENT TO CERN fix for missing virtual detector planes - ertrch.F PROBLEM: sometimes GEANE could not find virtual detector plane. This was due to the procedure to decide whether in a step the plane was reached or not: if the step is too big and the ending point of the step is on the other side of the plane the step size is reduced in order to have the final point on the plane itself (within a certain precision). if the ending point is right before the plane, so that STEP is not "greater or equal" to ASCL1, but their difference is of the order of GEANE used to act as there were enough space to perform this step and then tries another one before reaching the plane, BUT… plane reachedplane not reached: resizeprec limit: plane not found ASCL1 STEP ASCL1 STEP IF(STEP.GE.ASCL1) ASCL1 STEP STEP - ASCL1 ~

PATCH SENT TO CERN … doing this it fails in one of the checks it does at the beginning of the step: 1.it compares some quantities with the variable PREC (~ ) and there is the failure: we have too small quantities here (our /10 -8 ) 2.it looks for geometrical boundaries, but we are talking about virtual detector planes and it does not find them  it decides to perform too big steps and it does not find the plane! SOLUTION: we consider the plane as reached if the distance of the ending point to/from the plane is less than PREC. prec limit: plane not found ASCL1 STEP STEP - ASCL1 ~

TRACK LENGTH = 0 When the PropagateToLength is used to extrapolate to a very little track length, i.e. 0 or below PREC limit, the code used to fail. Now we force the tracklength to be = PREC if chosen track length is different from 0 but < PREC. If it is = 0 we force GEANE not to move. Test were performed with an “ad hoc” macro to propagate to a determined track length and it works. To verify whether the changes changes the usual results or not, tests were performed with: 1.the STT alone 2.the full detector with STT 3.The full detector with TPC with and without the change: in the common code the changes do not afflict the results.

TRACKING ALONG Z AXIS - problem The matrices for the error transportation in GEANE contain 1/cos  is the dip angle): this prevents from extrapolating along the z axis GEANE now exits with IERR = 4 when this case occurs, BUT sometimes, for rounding problems, it does not understand it is going along z, tries to make some steps and then fails with a crash To avoid these crashes and to be able to track almost along z we made a change …... 

Double_t cosLam0 = TMath::Sin(dir.Theta()); if(fabs(cosLam0) < 2.e-5) { Double_t cosLam = TMath::Sign(1., cosLam0) * 2.e-5; Double_t sinLam = TMath::Sqrt(1 - cosLam * cosLam); // px, py, pz dir.SetX(dir.X() * (cosLam/cosLam0)); dir.SetY(dir.Y() * (cosLam/cosLam0)); dir.SetZ(sinLam); dir.SetMag(1.); geant3->Gctrak()->vect[3] = dir.X(); geant3->Gctrak()->vect[4] = dir.Y(); geant3->Gctrak()->vect[5] = dir.Z(); } if(dir.Z() == 1) dir.SetMagThetaPhi(1., 1e-9, gRandom->Uniform(0., 2 * TMath::Pi())); 1. Check if the particle goes exactly along the z axis: if so, randomize its direction in  and give it a small , but ≠ 0: 2. Calculate cos : if it is smaller than , i.e. ≤ deg, renormalize the components of the direction vector to that limit: In this way you can never go below the imposed limit, and then you can never go along z TRACKING ALONG Z AXIS - correction

TRACKING ALONG Z AXIS - results 2000 muons, phi random [0°, 360°], theta = 0° GEANE x y z

TRACKING ALONG Z AXIS - results 2000 muons, phi random [0°, 360°], theta = 0° RUNGE KUTTA x y z

COMPARISON WITH RK efficiency issue

OUR CHECK OUR CHECK of the COMPARISON WITH RK efficiency issue We repeated the tests with the tpc/tpcreco/PndTpcGenfitTestTask.cxx, following the same scheme of the presentation and we got: No efficiency loss!!

COMPARISON WITH RK - STT alone 1000 – 1 GeV/c muons, random phi [0°, 360°], phi [0°, 180°]

Perspectives GEANE pro is interfaced with the MC geometry (including magnetic field) has the same tracking accuracy of GEANT3 contains the right mathematics for the error propagation takes into account bremsstrhalung (but not as Gaussian Sum) can be used as a benchmark for new codes GEANE contra the maintenance requires to modify the old FORTRAN CODE some instability due to C++/FORTRAN interfacing How to proceed?

Perspectives To implement GEANT4E in VMC implement the new RKTrackRep implement the new RKTrackRep with some extensions as the extrapolation with some extensions as the extrapolation to volumes to volumes to disentangle the Tracking from GENFIT to disentangle the Tracking from GENFIT and to implement new tracking classes in and to implement new tracking classes in ROOT ROOT RKTrackRep seems a good starting point for this RKTrackRep seems a good starting point for this

Concerning the physics…… an appropiate electron/positron energy loss straggling is missing necessary a new treatment of the radiation energy loss with the multiple gaussian parametrization of the energy straggling the multiple tracking should be allowed for the application of the Gaussian Sum Filter technique to the electron/positron track fitting

Conclusions GEANE is complete for the heavy particle tracking GEANE is complete for the heavy particle tracking good results obtained with RKTrack Rep good results obtained with RKTrack Rep electron/positron tracking is still incomplete. electron/positron tracking is still incomplete. The implementation of GSF is necessary The implementation of GSF is necessary the implementation of GEANT4E should be evaluated the implementation of GEANT4E should be evaluated the implementation of a new ROOT tracker the implementation of a new ROOT tracker is possible. This is just the right time to start is possible. This is just the right time to start

Back-up slies

TO DO LIST – EVO 07/10/2009  A general “restyling” of FairGeanePro is needed in some points, to uniform the function names and optimize them: for example PropagateToPCA(pca)/PropagateToPCA(pca, dir ) to be unified in one! DONE TO DO A MORE GENERAL IDEA Lia wrote the GeaneTrackRep::getPosMomCov function but there is a problem in the transformation to MARS, which may fail sometimes due to MARS/SD/SC transformations a comment is needed (and I will put the implementation in svn) Exception o f getMom in PndGenfitAdapters (see thread: Bugs, Fixes, Releases: Bug in GenfitTrack2PndTrack); we should decide whether to put it within a “try&catch” or to handle the exceptions directly inside getPos/Mom/PosMom/PosMomCov ? Bug in SPU still needs to be corrected (see forthcoming post in the forum) FINALLY, IN THE INTERFACE BETWEEN GEANE AND GENFIT DONE

PATCH SENT TO CERN This crash happens, thbough very rarely, in the part recently inserted to include bremsstrahlung LX = *STEP/RADL EMB=E/(2**LX) S2B=E*E*(1/3**LX - 1/4**LX) SB=SQRT(ABS(S2B)) DEDXB = 1.2*SB The calculation of **LX fails when LX is too big ( in thick materials, where RADL is small, or when big STEP s are performed): our SOLUTION is to put DEDXB = 0 and recalculate it only for LX<25 Program received signal SIGFPE, Arithmetic exception. [Switching to Thread (LWP 17211)] 0xb113115c in erland_ () from /home/spataro/jan10/transport/geant3/lib/tgt_linux/libgeant321.so (gdb) bt #0 0xb113115c in erland_ () from /home/spataro/jan10/transport/geant3/lib/tgt_linux/libgeant321.so #1 0xb113331d in ertrch_ () from /home/spataro/jan10/transport/geant3/lib/tgt_linux/libgeant321.so #2 0xb1133ded in ertrgo_ () from /home/spataro/jan10/transport/geant3/lib/tgt_linux/libgeant321.so #3 0xb in ertrak_ () from /home/spataro/jan10/transport/geant3/lib/tgt_linux/libgeant321.so #4 0xb11c1ecf in TGeant3::Ertrak () from fix for crash in electron tracking - erland.F

This crash used to happen in connection with the IERR = 3 flag, i.e. "H*ALFA/P AT X1 AND X2 DIFFER TOO MUCH”. There was a GOTO pointing back to a part of code where uninitialised variables were used. This used to produce a crash. Our SOLUTION is to skip the step where IERR = 3, getting rid of the wrong GOTO, but to update the initial point position, momentum and magnetic field value as well. We put a new flag, NOPRNT, to select whether printing or not the error messages PATCH SENT TO CERN #11 xmm55_ (a=0x433be198, b=0x433be168, c=0x433be168) at matx55/xmm55.F:42 #12 0x in trprfn_ (x1=0x4338f458, p1=0x0, h1=0x4338f470, x2=0x4338f494, p2=0x4338f4a0, h2=0x4338f4ac, ch=0x4338f4d0, xl=0x433be198, r=0xbfd8b950, mvar=0xbfd8b940, iflag=0xbfd8b944, itran=0x433be198, ierr=0xbfd8b94c) at erpremc/trprfn.F:376 #13 0x in erprop_ () at erdecks/erprop.F:62 #14 0x430665bb in ertrch_ () at erdecks/ertrch.F:322 #15 0x43066db2 in ertrgo_ () at erdecks/ertrgo.F:236 #16 0x43065be5 in ertrak_ (x1=0xa1b6d38, p1=0xa1b6d44, x2=0xa1b6cac, p2=0xa1b6cb8, ipa=0xffffffff, chopt=0xffffffff, __g77_length_chopt= ) at erdecks/ertrak.F:211 #17 0x430ef4b1 in TGeant3::Ertrak (this=0x9b1a5b0, x1=0x433be198, p1=0x433be198, fix for IERR = 3 error - trprfn.F/erprop.F