1 / 23

GEANE Status and perspectives

Comparison of tracking methods - tracking as random values vs tracking as mean values with errors. GEANE program treats the track as a 5-dimensional object and finds its points as mean values with errors.

fblair
Télécharger la présentation

GEANE Status and perspectives

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GEANEStatus and perspectives Lia Lavezzi and Alberto Rotondi

  2. Tracking • vs MC • fornewcomers track follower 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 following PANDA meeting, Vienna 1-5 september

  3. GEANE is a trackingprogram: ittreats the trackas a 5-dimensional object and findsitspointsasmeanvalueswitherrors • Meanvaluesdepends on magneticfield, ionizationenergy loss, radiationenergy loss • Errorsdepends on energy loss, multiple scattering and on the previoustrackhistory • Trackingisnecessaryfor global fitting (Kalmanfilter and GaussianSumFilter)

  4. 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 • Check on the tracking of anychargedparticle and ofneutralparticles • In thehelix<--> parabolacontructorssometimes the transformationisnotpossible and itfails: acommentisneededtoexplainwhy (itis due to the SD/SC transformationfailure) • PropagateToLength(0)mustbefixed (peraphs in FORTRAN) tobeableto propagate to track length = 0 (i.e. don’ t move) • Check the option'O’ ( = only); itshould the meanvalueswitout the errors. Ifitis so, afunctiontouseitmustbeaddedto the interface • Add the covariancematrix in MARS (6X6) inFairTrackParH • Check the trackingalong the zaxis • Fixbugtoprevent crash (e.g. in xmm55) IT WAS DECIDED THIS IS NOT NECESSARY DONE DONE DONE DONE DONE DONE

  5. PATCH SENT TO CERN(xmm55 crash & Co.) A patch hasbeen sent to CERN and the correctionshavebeenincluded in rev. 252 of geant3 The patch contains the previousredpoints and the followingcorrections: 1. fixfor crash in electron tracking - erland.F 2. fixformissingvirtual detector planes - ertrch.F

  6. PATCH SENT TO CERN - 3 - fixformissingvirtual 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 -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 plane not reached: resize prec limit: plane not found STEP STEP STEP ASCL1 ASCL1 ASCL1 STEP - ASCL1 ~ -10-7 IF(STEP.GE.ASCL1)

  7. PATCH SENT TO CERN - 3 - prec limit: plane not found STEP ASCL1 STEP - ASCL1 ~ -10-7 • … doingthisitfails in one of thechecksitdoes at thebeginning of thestep: • itcompares some quantitieswith the variable PREC (~ 10-4) andthereis the failure: wehavetoosmallquantitieshere (our 10-7/10-8) • itlooksforgeometricalboundaries, butwe are talkingaboutvirtual detector planes and itdoesnotfindthem • itdecidestoperformtoo big steps and itdoesnotfind the plane! • SOLUTION: weconsider the planeasreachedif the distance of the endingpointto/from the planeislessthan PREC.

  8. TRACK LENGTH = 0 When the PropagateToLengthisusedtoextrapolateto a very little tracklength, i.e. 0 orbelow PREC limit, the code usedtofail. Nowwe force thetracklengthtobe = PRECifchosen track lengthisdifferentfrom 0 but < PREC. Ifitis = 0we force GEANEnottomove. Test wereperformedwithan “ad hoc” macroto propagate to a determined track length and itworks. Toverifywhether the changeschanges the usualresults or not , testswereperformedwith: the STT alone the full detector with STT The full detector with TPC with and without the change: in the common code thechanges do notafflict the results.

  9. 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 … ... 

  10. 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.SetMagThetaPhi(1., 1e-9, gRandom->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 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(); } In this way you can never go below the imposedlimit, andthenyou can never go along z

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

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

  13. COMPARISON WITH RK efficiencyissue

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

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

  16. 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 Howtoproceed?

  17. Perspectives • Toimplement GEANT4E in VMC • implement the newRKTrackRep • with some extensionsas the extrapolation • tovolumes • todisentangle the Trackingfrom GENFIT • and toimplementnewtrackingclasses in • ROOT • RKTrackRepseems a goodstartingpointforthis

  18. 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

  19. Conclusions • GEANE is complete for the heavyparticletracking • goodresultsobtainedwithRKTrackRep • electron/positrontrackingisstill incomplete. • The implementationof GSF isnecessary • the implementationof GEANT4E shouldbeevaluated • the implementationof a new ROOT tracker • ispossible. Thisis just the right timeto start

  20. Back-up slies

  21. TO DO LIST – EVO 07/10/2009 • A general “restyling” ofFairGeaneProisneeded in somepoints, touniform the functionnames and optimizethem: forexamplePropagateToPCA(pca)/PropagateToPCA(pca, dir) tobeunified in one! A MORE GENERAL IDEA TO DO • Lia wrote the GeaneTrackRep::getPosMomCovfunctionbutthereis a problem in the transformationto MARS, whichmayfailsometimes due to MARS/SD/SC transformations a commentisneeded (and I will put the implementation in svn) • Exception of getMom in PndGenfitAdapters (seethread: Bugs, Fixes, Releases: Bug in GenfitTrack2PndTrack); weshould decide whetherto put itwithin a “try&catch” or tohandle the exceptionsdirectly inside getPos/Mom/PosMom/PosMomCov? • Bug in SPU stillneedstobecorrected (seeforthcoming post in the forum) FINALLY, IN THE INTERFACE BETWEEN GEANE AND GENFIT DONE DONE DONE

  22. PATCH SENT TO CERN - 2 - fixfor crash in electron tracking - erland.F Program receivedsignal SIGFPE, Arithmeticexception.[SwitchingtoThread -1208060224 (LWP 17211)]0xb113115c inerland_ () 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 0xb1132747 in ertrak_ () from /home/spataro/jan10/transport/geant3/lib/tgt_linux/libgeant321.so#4 0xb11c1ecf in TGeant3::Ertrak () from This crash happens, thboughveryrarely, in the partrecentlyinsertedto include bremsstrahlung LX = 1.442695*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 **LXfailswhenLXistoo big ( inthickmaterials, whereRADLissmall, orwhen big STEPs are performed): our SOLUTION istoputDEDXB = 0 and recalculateitonlyforLX<25

  23. PATCH SENT TO CERN - 1 - fixfor IERR = 3 error - trprfn.F/erprop.F #11xmm55_ (a=0x433be198, b=0x433be168, c=0x433be168) at matx55/xmm55.F:42#12 0x43069289 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) aterpremc/trprfn.F:376#13 0x43065326 in erprop_ () aterdecks/erprop.F:62#14 0x430665bb in ertrch_ () aterdecks/ertrch.F:322#15 0x43066db2 in ertrgo_ () aterdecks/ertrgo.F:236#16 0x43065be5 in ertrak_ (x1=0xa1b6d38, p1=0xa1b6d44, x2=0xa1b6cac, p2=0xa1b6cb8,ipa=0xffffffff, chopt=0xffffffff, __g77_length_chopt=1126230360) aterdecks/ertrak.F:211#17 0x430ef4b1 in TGeant3::Ertrak (this=0x9b1a5b0, x1=0x433be198, p1=0x433be198, 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

More Related