GSI Helmholtzzentrum für Schwerionenforschung
On 02.03.2012 at 15:03 wrote Andrey Lebedev: 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
Re: Coordinate system for hit parameters
On 02.03.2012 at 15:28 wrote David Emschermann: 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
On 02.03.2012 at 17:16 wrote Andrey Lebedev: 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
I am also not sure whether I get the question right. Do you mean by "generated by geant" that the geometry was created from the ASCII file, in contrast to being created directly in ROOT (TGeo) format? 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.
Many years ago, in the stone ages of cbmroot, we decided to store the parameters of hits, tracks etc. in the global coordinate system. The reasons were: 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.
I don't think that it is possible to use global coordinates for 1-D detectors (straw tubes, etc.) - for U, V views, for example. I suppose, STS tracking experts could clarify this since they work with strip detectors.
Why do you think it is not possible? In any case it should be possible to go back and forth from global to local coordinates. 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.
I can't imagine what would be the global coordinates for a rotated straw tube hit (let say, at 45 degs with respect to 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.