Presentation is loading. Please wait.

Presentation is loading. Please wait.

I.BelikovWeekly Offline Meeting, CERN, 14 Sep 20061 Common track parameterization for the barrel detectors.

Similar presentations


Presentation on theme: "I.BelikovWeekly Offline Meeting, CERN, 14 Sep 20061 Common track parameterization for the barrel detectors."— Presentation transcript:

1 I.BelikovWeekly Offline Meeting, CERN, 14 Sep 20061 Common track parameterization for the barrel detectors.

2 I. BelikovWeekly Offline Meeting, CERN, 14 Sep 20062 What parameterization means Infinite number of possibilities. For a (naïve) example: {x, y, z, px, py, pz} The parameterization above is often excessive for the reconstruction purposes (“points” are constrained to “surfaces”). Minimalist’s {y, z, px, py, pz} is better. Still not perfect. For straight-line tracks 3 out of 5 parameters are not defined. {y, z, , , p} is better. And so on. There might be many other considerations… Track parameterization is a set of values that define (locally or globally) this track. (x,y,z) (px,py,pz) (x1,y1,z1) (px1,py1,pz1) (x2,y2,z2) (px2,py2,pz2)

3 I. BelikovWeekly Offline Meeting, CERN, 14 Sep 20063 Software considerations Under condition of reasonable overall design and programming style (coding conventions !), the track parameterization concerns only the implementation. This freedom can be used for improving The speed of calculations Numerical stability of the calculations Overall maintainability of the code in a transparent for the rest of the reconstruction code way.

4 I. BelikovWeekly Offline Meeting, CERN, 14 Sep 20064 “Pre-PPR” design (since 1998) We were not much concerned by the code maintainability (a very simple code, only a few developers, no reconstruction working group PWG1). The numerical stability was not yet an issue (little number events, no data challenges). HLT, analysis and C&A did not start yet. On the other hand We wanted to try several possibilities. We did think about the growth of the code and involvement of many developers (“democratic” design) Abstract class AliKalmanTrack fixes the interface virtual Int_t PropagateTo(…) = 0; virtual Double_t PredictedChi2(…) = 0; virtual Int_t Update(…) = 0; Derived classes fix the detector specific track parameterization and implementation. (three kinds of them survived the time) The main objective was the ALICE detector performance studies. AliKalmanTrack AliITStrackV2 AliTPCtrackAliTRDtrack AliTOFtrack

5 I. BelikovWeekly Offline Meeting, CERN, 14 Sep 20065 “Post-PPR” design (since 2006) The main objective is reconstruction and physics analysis of real data. AliKalmanTrack AliTOFtrack AliITStrackV2AliTRDtrack AliTPCtrack Stability and maintainability are the issues ! The AliExternalTrackParam class fixes the common track parameterization and the implementation of “elementary” functions Bool_t PropagateTo(…); Bool_t Rotate(…); Double_t PredictedChi2(…); Bool_t Update(…); Bool_t CorrectForMaterial(…) And a few useful others Derived classes still can do something specific, however they mainly delegate the execution to the base class: Bool_t AliTPCtrack::Update(…) { … // Get the TPC specific cluster position errors … if ( !AliExternalTrackParam::Update(…) ) return kFALSE; … … // something else TPC specific } AliExternalTrackParam AliESDtrack To reconstruction To alignment and analysis AliITStrackMI AliL3ITStrack AliITStrackSA AliL3HoughKalmanTrack

6 I. BelikovWeekly Offline Meeting, CERN, 14 Sep 20066 Conclusions  From now on the reconstruction in the core (ITS, TPC, TRD, TOF) barrel detectors, as well as the HLT, analysis and alignment, share the common track parameterization. This parameterization is: {y, z, sin(  ), tan( ), 1/pt} The common “elementary” tracking functions are now implemented in the base AliExternalTrackParam class and so are also shared. This reduces the number lines of the code, and (should) increases numerical stability and maintainability of the code, And makes it easier to re-implement the elementary functions once more, if we find it necessary (example: transverse components of the magnetic field). Shall we change the names ? AliExternalTrackParam -> AliKalmanTrack, (two reasons) AliKalmanTrack -> Ali(Whatever, Core ?)Track (one but clear rsn)

7 I. BelikovWeekly Offline Meeting, CERN, 14 Sep 20067 PWG1: List of things to be done (see also Physics Forum 15.03.2006, and Weekly Offline 18.05.2006) Reconstruction of the TPC cosmic dataM.Ivanov, C.Cheshkov 05/200606/2006 OK Primary vertex reconstruction. Measurement of the beam position. M.Masera, F.Riggi 05/200606/2006 OK Calling (interfacing) the primary “VertexerTracks” from AliReconstruction I.Belikov05/2006 OK Sharing (via inheritance) the code between the reconstruction, alignment and physics analysis. I.Belikov04/200608/2006 OK Unification of the vertex classes (V0s, cascades, kinks, n-prong) B.Hippolyte, M.Ivanov 04/200609/2006 Factorization of the reconstruction “features”M.Ivanov, I.Belikov ???By 10/2006 ? Beam-beam pile-up removal, TPCC.Cheshkov200509/2006 Beam-gas pile-up removal, TPCC.Cheshkov, A.Morsch, M.Kowalski ? 200609/2006 Who Started on Finished on

8 I. BelikovWeekly Offline Meeting, CERN, 14 Sep 20068 PWG1: List of things to be done Electron PID with the TRD.S.Masciocchi04/2006 Bremsstrahlung corrections.Sb from Athens ?05/2006 TRD tracking using tracklets.???09/2006 New ! ITS material budget via TGeo.M.Ivanov Maintaining the ESD libraryI.Belikov2004Never ends Checking the reconstruction qualityA.Mazzoni05/2006 Monitoring the CPU/RAM consumptionP.Hristov, I.Belikov Started long ago Never ends Who Started on Finished on


Download ppt "I.BelikovWeekly Offline Meeting, CERN, 14 Sep 20061 Common track parameterization for the barrel detectors."

Similar presentations


Ads by Google