GEANE Status and perspectives Lia Lavezzi and Alberto

GEANE Status and perspectives Lia Lavezzi and Alberto Rotondi

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

• 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 (Kalman filter and Gaussian. Sum. Filter)

TO DO LIST – EVO 07/10/2009 In the new CERN release and in the FAIR Root interface New GEANE PATCH BUG FIXES AND THINGS TO BE ADDED IT WAS DECIDED THIS ü Check on the tracking of any charged particle and of neutral particles IS NOT NECESSARY ü 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) üPropagate. To. Length(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 (6 X 6) in Fair. Track. Par. H ü Check the tracking along the z axis ü Fix bug to prevent crash (e. g. in xmm 55) DONE DONE

PATCH SENT TO CERN (xmm 55 crash & Co. ) A patch has been sent to CERN and the corrections have been included in rev. 252 of geant 3 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 - 3 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 ASCL 1, but their difference is of the order of -10 -7 GEANE used to act as there were enough space to perform this step and then tries another one before reaching the plane, BUT… plane reached STEP plane not reached: resize prec limit: plane not found ASCL 1 IF(STEP. GE. ASCL 1) STEP - ASCL 1 ~ -10 -7

PATCH SENT TO CERN - 3 prec limit: plane not found STEP ASCL 1 STEP - ASCL 1 ~ -10 -7 … 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 (~ 10 -4) and there is the failure: we have too small quantities here (our 10 -7/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.

TRACK LENGTH = 0 When the Propagate. To. Length 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 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/cosl (l 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 … . . .

TRACKING ALONG Z AXIS - correction 1. Check if the particle goes exactly along the z axis: if so, randomize its direction in f and give it a small q=90 -l, but ≠ 0: if(dir. Z() == 1) dir. Set. Mag. Theta. Phi(1. , 1 e-9, g. Random->Uniform(0. , 2 * TMath: : Pi())); 2. Calculate cosl: if it is smaller than 2. 10 -5, i. e. l ≤ 10 -3 deg, renormalize the components of the direction vector to that limit: Double_t cos. Lam 0 if(fabs(cos. Lam 0) Double_t = TMath: : Sin(dir. Theta()); < 2. e-5) { cos. Lam = TMath: : Sign(1. , cos. Lam 0) * 2. e-5; sin. Lam = TMath: : Sqrt(1 - cos. Lam * cos. Lam); // px, py, pz dir. Set. X(dir. X() * (cos. Lam/cos. Lam 0)); dir. Set. Y(dir. Y() * (cos. Lam/cos. Lam 0)); dir. Set. Z(sin. Lam); dir. Set. Mag(1. ); geant 3 ->Gctrak()->vect[3] = dir. X(); geant 3 ->Gctrak()->vect[4] = dir. Y(); geant 3 ->Gctrak()->vect[5] = dir. Z(); } In this way you can never go below the imposed limit, and then you can never go along z

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

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

COMPARISON WITH RK efficiency issue

OUR CHECK of the COMPARISON WITH RK efficiency issue We repeated the tests with the c i f ef y c n e i tpc/tpcreco/Pnd. Tpc. Genfit. Test. Task. cxx , following the same scheme of the presentation and we got: No ! ! s s lo

COMPARISON WITH RK - STT alone 1000 – 1 Ge. V/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 GEANT 3 • 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 GEANT 4 E in VMC • implement the new RKTrack. Rep with some extensions as the extrapolation to volumes • to disentangle the Tracking from GENFIT and to implement new tracking classes in ROOT RKTrack. Rep 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 • good results obtained with RKTrack Rep • electron/positron tracking is still incomplete. The implementation of GSF is necessary • the implementation of GEANT 4 E should be evaluated • the implementation of a new ROOT tracker is possible. This is just the right time to start

Back-up slies

TO DO LIST – EVO 07/10/2009 A MORE GENERAL IDEA X A general “restyling” of Fair. Geane. Pro is needed in some points, to uniform the function names and optimize them: for example Propagate. To. PCA(pca)/Propagate. To. PCA(pca, dir) to be unified in one! TO DO FINALLY, IN THE INTERFACE BETWEEN GEANE AND GENFIT ü Lia wrote the Geane. Track. Rep: : get. Pos. Mom. Cov 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 of get. Mom in Pnd. Genfit. Adapters (see thread: Bugs, Fixes, Releases: Bug in Genfit. Track 2 Pnd. Track); we should decide whether to put it within a “try&catch” or to handle the exceptions directly inside get. Pos/Mom/Pos. Mom. Cov? ü Bug in SPU still needs to be corrected (see forthcoming post in the forum) DONE

PATCH SENT TO CERN - 2 fix for crash in electron tracking - erland. F Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1208060224 (LWP 17211)] 0 xb 113115 c in erland_ () from /home/spataro/jan 10/transport/geant 3/lib/tgt_linux/libgeant 321. so (gdb) bt #0 0 xb 113115 c in erland_ () from /home/spataro/jan 10/transport/geant 3/lib/tgt_linux/libgeant 321. so #1 0 xb 113331 d in ertrch_ () from /home/spataro/jan 10/transport/geant 3/lib/tgt_linux/libgeant 321. so #2 0 xb 1133 ded in ertrgo_ () from /home/spataro/jan 10/transport/geant 3/lib/tgt_linux/libgeant 321. so #3 0 xb 1132747 in ertrak_ () from /home/spataro/jan 10/transport/geant 3/lib/tgt_linux/libgeant 321. so #4 0 xb 11 c 1 ecf in TGeant 3: : Ertrak () from This crash happens, thbough very rarely, in the part recently inserted to include bremsstrahlung LX = 1. 442695*STEP/RADL EMB=E/(2**LX) S 2 B=E*E*(1/3**LX - 1/4**LX) SB=SQRT(ABS(S 2 B)) DEDXB = 1. 2*SB The calculation of **LX fails when LX is too big ( in thick materials, where RADL is small, or when big STEPs are performed): our SOLUTION is to put DEDXB = 0 and recalculate it only for LX<25

PATCH SENT TO CERN - 1 fix for IERR = 3 error - trprfn. F/erprop. F #11 xmm 55_ (a=0 x 433 be 198, b=0 x 433 be 168, c=0 x 433 be 168) at matx 55/xmm 55. F: 42 #12 0 x 43069289 in trprfn_ (x 1=0 x 4338 f 458, p 1=0 x 0, h 1=0 x 4338 f 470, x 2=0 x 4338 f 494, p 2=0 x 4338 f 4 a 0, h 2=0 x 4338 f 4 ac, ch=0 x 4338 f 4 d 0, xl=0 x 433 be 198, r=0 xbfd 8 b 950, mvar=0 xbfd 8 b 940, iflag=0 xbfd 8 b 944, itran=0 x 433 be 198, ierr=0 xbfd 8 b 94 c) at erpremc/trprfn. F: 376 #13 0 x 43065326 in erprop_ () at erdecks/erprop. F: 62 #14 0 x 430665 bb in ertrch_ () at erdecks/ertrch. F: 322 #15 0 x 43066 db 2 in ertrgo_ () at erdecks/ertrgo. F: 236 #16 0 x 43065 be 5 in ertrak_ (x 1=0 xa 1 b 6 d 38, p 1=0 xa 1 b 6 d 44, x 2=0 xa 1 b 6 cac, p 2=0 xa 1 b 6 cb 8, ipa=0 xffff, chopt=0 xffff, __g 77_length_chopt=1126230360) at erdecks/ertrak. F: 211 #17 0 x 430 ef 4 b 1 in TGeant 3: : Ertrak (this=0 x 9 b 1 a 5 b 0, x 1=0 x 433 be 198, p 1=0 x 433 be 198, This crash used to happen in connection with the IERR = 3 flag, i. e. "H*ALFA/P AT X 1 AND X 2 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