Status of new tracking data model Enduser Classes

Status of new tracking data model “End-user” Classes Jose Hernando (CERN) , Eduardo Rodrigues (NIKHEF) In short … Driving idea: Ø agree on the interfaces Ø move the code adiabatically in steps code always working, smooth implementation of the interfaces Visible to the user: Ø tracks & states Ø propagators To help the tracking/pattern recognition developers: Ø nodes & measurements Ø projectors Details on status of implementation: http: //cern. ch/eduardo. rodrigues/lhcb/tracking/event_model/index. html ( note: place of evolving ideas/implementations … ) Reconstruction Meeting, 2 nd November 2004 1

Working plan 1. Reach agreement on Tr. Track, Tr. State, extrapolators interface q GOAL: standard output of all fitting algorithms, online & offline Ø client interface: how to use the tracks, … Ø minimal interference with present code e. g. leave measurements untouched at this stage q STEPS: 1 a) reach final agreement on this set of classes (today? ) 1 b) implementation of converters Ø Tr. Fit. Track. To. Track. Cnv & Trg. Track. To. Track. Cnv needed to make sure the Tr. Tracks work ! 2 a) make Tr. Fit. Track & Trg. Track inherit from Tr. Track Ø at this point we could already imagine some full MC production with new model ! q TIMESCALE: 1 a) end of the week 1 b) 1 week after agreement (implementation + test) 2 a) 2 weeks Reconstruction Meeting, 2 nd November 2004 2

Working plan 2. Reach agreement on Tr. Measurement, Tr. Node, projectors interface q GOAL: have some common base classes for pattern recognition and fitting algorithms Ø re-use as much as possible the existing code and packages Ø Tr(g)Event minimally/not touched Ø end-user/client code is unchanged ! q STEPS: 1 a) get some first agreement on proposed structure Ø projectors as Gaudi tools, need for Tr. Measurement & Tr. Node classes 1 b) re-build all necessary info from persistency 2 a) Xxx. Cluster. On. Track replaced by Tr. Node, Xxx. Cluster derived from Tr. Measurement 2 b) pattern recognition and fitting algorithms make full use of projectors and new measurement classes Reconstruction Meeting, 2 nd November 2004 3

Tr. Tracks (1/2) Data members Ø m_type: OK. Related enums are no problem to persistency variation: make use of bitfields Ø m_history. Flag: OK. Enum. variation: change the name? Ø m_error. Flag: renamed to m_flag. Uses bitfields with contents = { valid, … } Ø m_chi 2: becomes m_chi 2 Per. Do. F more commonly used Ø m_n. Do. F: keep it? -> pros: fast access to info variation: remove it -> pros: saves space, but needs some calculations to get it back Ø m_closest. State: state closest to beam-line, to be persistent more commonly used variation: call it m_first. State Ø m_states: proposal to have a Smart. Ref. Vector persistency on demand: subset of states to be persistified (Beam-line, TT, T) variation: use a std: : map with location as key (e. g. At. TT) Reconstruction Meeting, 2 nd November 2004 4

Tr. Tracks (2/2) Public methods Ø end-user methods for fast/easy access to general track information e. g Status. Code position. And. Momentum (double z, ITr. Extrapolator *extrapolator, Particle. ID &pid, Hep. Point 3 D &pos, Hep. Vector 3 D &mom, Hep. Sym. Matrix &cov 6 D) Ø methods to get direct access to closest state, by z-pos or plane commonly used methods in tracking code -> pros: friendly and simple interface Ø methods with extrapolator interface as argument: -> pros: hide repeated operations (e. g. a. Track->closest. State()->extrapolate() ) variation: move these methods to the extrapolator interface Ø virtual methods: # brought to a minimum closest. State(z/Hep. Plane 3 D), reset(), clone(), produced. By. Algo() Reconstruction Meeting, 2 nd November 2004 5

Tr. States Data members Ø m_type: enum {Straight. Line, Has. Momentum} Fine Ø m_location: enum key for state locations (e. g. At. TT, Beg. RICH 1, …) Ø other data members: z-position, state vector, covariance Public methods Ø # of “setter” methods minimized Ø methods related to position/slopes: implemented no need to be virtual Ø methods with Q/P or momentum: all virtual Derived classes Ø 2 strategies to derive from Tr. State: Tr. State. L -> Tr. State (Q/P and 5 components) Tr. State. L, Tr. State. P -> Tr. State Reconstruction Meeting, 2 nd November 2004 6

Tools - extrapolators ITr. Extrapolator Public methods Ø extrapolators to z and Hep. Plane 3 D virtual Status. Code propagate (Tr. State *state, double z, Particle. ID part. Id=Particle. ID(211))=0 Ø Issue: need for an extrapolation to some kind of surface How to define a surface? Can use fosr the moment a typedef to Hep. Plane 3 D in a “Surface” class Ø interface ITr. Extrapolator defined and essentially agreed … Tr. Linear. Extrapolator Public methods Ø already implemented Ø serves as (simple) example Reconstruction Meeting, 2 nd November 2004 7