7
1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

Embed Size (px)

Citation preview

Page 1: 1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

1

Request for MuDst revision

Y.Fisyak, 03/05/08 S&C meeting

Page 2: 1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

2

The reasons• MuDst design was done a few years ago based on tpt + egr + evr

(TPT) tracks and vertices reconstruction in TPC. The main problems of this reconstruction are:– we are limited reconstruction in TPC only,

– we don’t understand and we don’t trust errors of fit parameters.

• “New” tracker (STI) took over on “Old” one (TPT) about 2 years ago and:– we do understand and we do trust errors of fit parameters estimation.

• The tasks which I try to formulate are:– Do we need this understanding (use case)?

– How can we use this understanding in analysis ?

– How we can modify MuDST to access the information in analysis ?

Page 3: 1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

3

Use case• One of the main goals of AuAu Run VII is detection of open charm

signal with Silicon detectors:– main tool is measurement of decay length (L) for secondary vertex

with two or more tracks and estimation from these tracks parameters and their covariance matrices its precision (L).

• Presence of covariance matrix also allows us:– To evaluate quality of track reconstruction.

• I would like to have a possibility to select good track from condition, for example, that track p/p > 30%, instead comparison between number of fitted and possible hits.

– To estimated precision of any values calculated from tracks, for example, error in effective mass.

– etc, …

Page 4: 1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

4

MuDstWe have two types of tracks:

– Global one: • with parameters (dcaXY, dcaZ, ,q/pT, tan(), curvature = Hz q/pT ) and

• covariance matrix of the above parameters (5*6/2 = 15 words)

• Total size (StDcaGeometry) (6 + 15)*4 = 84 bytes.

– Primary one:• with parameters (,q/pT, tan()) and

• covariance matrix (3*4/2 = 6 words)

• Total size 36 bytes.

– The proposal is to add the above parameters and their covariance matrix as two additional branches in MuDst TTree with navigation from global and primary (StMuTrack), respectively.

Page 5: 1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

5

MuDst size• Adding 86 bytes and 36 bytes for each global and primary track

significantly increase size of MuDst (StMuTrack size if 360 bytes). This means that we increase size of MuDst by ~25%.

• Can we reduce size of StMuTrack ?– We have two StMuHelix : mHelix and mOuterHelix with size of disk 30

bytes. Do we need them at all ? Inner Helix can be built from fit parameters. Outer Helix cannot be built. Do we need it ? (-60 bytes)

– We have two 3D DCA ? Again with fit parameters stored we can drop them ? (-24 bytes)

– Track parameters are stored twice as pT, Eta, Phi and as 3-vector (px,py,pz) (-12 bytes)

– We have the same class (StMuTrack) for both global and primary tracks which have redundant information for hits, fits, PiD, dEdx and etc flags / parameters. Create new StMuPrimaryTrack and take the above information from Global track (StMuTrack). (-30 bytes).

• Thus it is visible – To add full track fit information and – Even to reduce the size of MuDst.

• The question is : What will be impact on physics analysis and back compatibility of analysis codes ?

Page 6: 1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

6

Conclusion• We need full information from Track fit including covariance

matrix.• Just adding this information will increase size of MuDst on disk

by ~25%• Redesign on MuDst can recover this extra size.• The question is how this reduction will affect physics analysis

including code back compatibility. To answer on this question we need a response from PWG.

Page 7: 1 Request for MuDst revision Y.Fisyak, 03/05/08 S&C meeting

7

•sizeof(StMuTrack) (const int)372 - 12 bytes (TObject + pointer to table of virtual functions) = 360• 2 2 Short_t mId;• 2 4 Short_t mType;• 2 6 Short_t mFlag;• 4 10 Int_t mIndex2Global;• 4 14 Int_t mIndex2RichSpectra;• 4 18 Int_t mVertexIndex; // Primary vertex id for this track's dca• 1 19 UChar_t mNHits; // Total number of points (was (F)tpc only)• 1 20 UChar_t mNHitsPoss; // Total possible points (was (F)tpc only)• 1 21 UChar_t mNHitsDedx; • 1 22 UChar_t mNHitsFit; // Total fitted points (was (F)tpc only)• 1 23 UChar_t mNHitsPossInner; // Svt/Ist (3 bit) and Ssd (2 bit) possible hits, Pixel (3 bits)• 1 24 UChar_t mNHitsFitInner; // Svt/Ist (3 bit) and Ssd (2 bit) fitted hits, Pixel (3 bits)•† 1 25 UChar_t mNHitsPossTpc; // Possible (F)tpc hits (Ftpc flagged with first 2 bits)• 1 26 UChar_t mNHitsFitTpc; // Fitted (F)tpc hits (Ftpc flagged with first 2 bits)• 2 28 UShort_t mPidProbElectron;• 2 30 UShort_t mPidProbPion;• 2 32 UShort_t mPidProbKaon;• 2 32 UShort_t mPidProbProton;• 4 36 Int_t mNSigmaElectron;• 4 40 Int_t mNSigmaPion;• 4 44 Int_t mNSigmaKaon;• 4 48 Int_t mNSigmaProton;• 4 52 Float_t mdEdx;• 4 56 Float_t mChiSqXY;• 4 60 Float_t mChiSqZ;• 4 64 Float_t mPt;• 4 68 Float_t mEta;• 4 72 Float_t mPhi;• 20 92 StTrackTopologyMap mTopologyMap;• 12(16) 104 StThreeVectorF mP;• 12 116 StThreeVectorF mDCA;• 12 128 StThreeVectorF mDCAGlobal;• 12 140 StThreeVectorF mFirstPoint;• 12 152 StThreeVectorF mLastPoint;• 52 204 StMuHelix mHelix;• 52 256 StMuHelix mOuterHelix;• 72 328 StMuProbPidTraits mProbPidTraits;• 4 332 Float_t mSigmaDcaD;• 4 336 Float_t mSigmaDcaZ;