The geane coordinate system is different from the panda coordinate system. In geane the beam is going along x: (x,y,z) -> (z,y,-x)

Why is this so? In principle GEANE does not need the information of the beam axis. All relevant information is in the geometry and the field. Both data sets are available in the panda coordinate system. Where are they converted?

Using two different coordinate system creates a mess in the tracking.

Regards, Sebastian.]]>

Now what is right? How are the covariances ordered?

Cheers!

Sebastian.]]>

is, as far as I know, historical and we had adopted this

convention to properly call geane. We can perhaps think

of a different approach, but in all our tests it did not seem

necessary so far.

Regarding CbmTrackParP, I think the comment is not correct:

all the calculations in SD are internally done with the

convention (q/p,v',w',v,w). See for instance the calculation

of the covariance matrix in SD, where we write:

...

fDQp = TMath::Sqrt(fabs(fCovMatrix[0]));

fDTV = TMath::Sqrt(fabs(fCovMatrix[5]));

fDTW = TMath::Sqrt(fabs(fCovMatrix[9]));

fDV = TMath::Sqrt(fabs(fCovMatrix[12]));

fDW = TMath::Sqrt(fabs(fCovMatrix[14]));

...

See also our report for the SD definition.

Hope this helps.

Ciao,

Andrea]]>

regarding the comments in geane and trackbase, I am working

on them. Some are obsolete and need to be removed.

Andrea]]>

Hope this helps.

Ciao,

Lia.]]>

we believe that in some cases the transformation

(x,y,z) -> (z,y,-x) that we tried at GSI the other day

works correctly, but it is not general. The correct way

to transform is the FromSCToMars suggested by Lia: in this

way the transformation between the two systems is properly

taken into account.

Ciao,

Andrea]]>

I will think about the (x,y,z)->(z,y,-x) transformation again. However we do not need (and I do not use) SC (at the moment). Only SD and in this case there is no need to have any one distinguished axis.

My question is: where is the transformation done for the Geometry and the Field?

Anyhow - I am working on GeaneTrackRep to hide all this.

Sebastian.]]>

be done for the geometry and the field.

In CbmTrackParP the track is defined in the SD system with

a detector plane defined by the user: the track parameters

and the errors are calculated on this plane but the tracking

internally (in ERTRAK) is done always in MARS. So there is

no need to transform geometry and field.

Perhaps we did not understand your question: if our reply

is not satisfactory, can you please add more details to your

question?

Andrea and Lia]]>

My question is only this: Are the coordinates of our geometry transformed in geane? Probably not. So why do we have to do the trafo at all? The only reason would be, that we want the SC angles to be meassured with respect to the beam, right?

Sebastian.]]>

The only transformations are in the definition of the track

parameters and in their errors calculation: these can be done

in SC or SD and can be transformed in MARS after the tracking.

At this point MARS for geane is identical to MARS for Panda.

In the first tutorial we shot along x axis, but it was

only to keep things simple: in the second tutorial we shot

isotropically in the Panda (MARS) system, so there is nothing

special about x axis. In SC angles are already defined in

MARS as azimuthal and polar angles. If the track is in SD

you have to calculate them by transforming to SC.

We hope this is clear now.

Ciao,

Andrea and Lia

]]>

Ok. Very good! Thank you for the clarification. So we do not need to bother with any transformation, because all that is needed is already in TrackParP.

Cool! Sebastian.]]>

I have look into CbmTrackParP and I found the place where the confusion sets in:

TVector3 positionsd = util.FromMARSToSDCoord(TVector3(fX, fY, fZ), forigin, fiver, fjver, fkver); fU = positionsd.X(); // CHECK fV = positionsd.Y(); // CHECK fW = positionsd.Z(); // CHECK

Since fV and fW are used in the trackrepresentation it is implicetely assumed, that X is along the track. So it has indeed nothing to do with the beam-axis.

In other words:

I would like to have: pos=(1,1,0) mom=(0.1,0,1) in MARS

when being projected onto a plane

o(0,0,0) u(1,0,0) v(0,1,0)

to give

v=1; w=1; v'=0.1; w'=0;

this is currently not the case because of the code shown above.

instead one would get

u=1; v=1; u'=0.1; v'=0;

In principle we should use fU and fV or build in some conversion somewhere.

Still thinking about it....

Cheers! Sebastian.

]]>

So understood some more.

The problem is that I interpret my DetPlane different than the geane-convention.

I always think that the detectorplane is spanned by x and y (which could be rotated to u and v).

In Geane v,w (corresponding to y,z) of the plane are assumed to span the plane.

...]]>

Ok. It works. Sorry for the confusion!

There will be demo with the GeaneTrackRep in Action soon.

Cheers and have a nice Weekend! Sebastian]]>

In recotasks/demo

there is a demo scipt which shows how the GeaneTrackRep and a DemoRecoHit are used to caluclated residuals.

Cheers!

Sebastian.]]>