Quote: |

Dear Colleagues, we have recently some discussions about which coordinate system to use to store hit information. With this mail I want to start a further discussion on this topic. Currently, hit position and corresponding errors are stored in global coordinate system (in a plane which is perpendicular to beam direction). However, introducing rotated outer planes in TRD we have to define how to store hit information, namely, in which coordinate system. In order to be consistent with current definitions, I would say that we have to stick to global coordinate system. This would be also easier for tracking to have all hits in the same coordinate system. However, hit producers has to be modified and implement rotation of the hit coordinates and errors. Best regards, Andrey |

Quote: |

Does it make a difference for the hit producer, if the underlying geometry was genereated with geant or with root? Is it easier to retrive the local to master transformation matrix, if the object was defined in root? Or is there no difference at all? Best regads David |

Quote: |

Hello David, I did not understand your question. We are talking about the information which has to be stored in file. Of cause local to global transformations are possible during runtime, but according to current convention we use global coordinate system for all hits and track parameters which are stored in the ROOT file. Best regards, Andrey |

]]>

Well, that does not make any difference, since the internal geometry is always built in TGeo format. If you intialise the geometry from ASCII, the geometry reader takes care of creating the ROOT geometry from this particular input. The TGeo is also the one written to the parameter file and, if specified in the macro, also to the additional geometry output file (by the method FairRunSim::CreateGeometryFile).

Now, the TGeo package provides you with convenient methods for coordinate transformation, in particular from local to global coordinates.

]]>

- Global coordinates allow a straightforward interpretation. Local coordinates always need the context of the detector geometry.
- It is supposedly easier for tracking, which connects hits from different detectors / stations / modules, to work with global coordinates.

I think these reasons still hold nowadays. Of course, for the creation of hits from digis, the local coordinate system is the relevant one. That means that after the creation of the hits in a particular piece of detector, their coordinates (and the covariance matrix) have to be transformed into the global coordinate system. The computational costs for this are most probably much less than the repeated transformations needed otherwise during track finding and fitting.

Note that the above holds strictly only for the persistent data objects (i.e. those put into the TClonesArray of the cbmsim TTree). Both the hit finders and the tracking algorithms can transiently use whatever data format they consider appropriate.

]]>

example. I suppose, STS tracking experts could clarify this since

they work with strip detectors.

]]>

For example for clustering and hit finding it can be more convenient to use local coordinate system with respect to module. And for the global tracking it would be much easier to use global coordinate system in all detectors.]]>

the vertical direction) and their errors - in fact, we discussed

this issue quite some time ago. In any case, it would be useful

to talk to STS tracking people.

]]>