update TrackerHitPlane doc #160
Conversation
updating the doc for `TrackerHitPlan` after clarifying the meaning of `u` and `v`
| - float du //measurement error along the direction | ||
| - float dv //measurement error along the direction | ||
| - edm4hep::Vector3d position //hit position in [mm]. |
There was a problem hiding this comment.
if I understand it right U defines the X axis and V defines the Y axis for position. the Z component will be ignored then?
what is also not clear to me: why is there a du and dv if there is also a covMatrix that describes the covariance of position
There was a problem hiding this comment.
This class has been copied from LCIO - see here for a more complete documentation: https://ilcsoft.desy.de/LCIO/current/doc/doxygen_api/html/classEVENT_1_1TrackerHitPlane.html.
The measurement directions u,v are the two directions of the measurement surface in global (polar) coordinates. The du, dv are the resolutions along these directions, i.e. the point resolution. So u,v are not really X and Y.
The covMatrix is given in the global cartesian coordinate and can be given for all types of TrackerHits
There was a problem hiding this comment.
thank you @gaede ! will the position contain then the U V values in form of X Y? this is where I get confused because you said covMatrix will be in global cartesian coordinates
There was a problem hiding this comment.
No, u,v really should be in (theta, phi), i.e spherical (and not polar coordinates). The global cartesian covariance matrix is a left-over from a time when there was only the generic TrackerHit in LCIO.
One could think about dropping this from EDM4hep...
There was a problem hiding this comment.
but U and V will only span the measurement direction for the plane, right? as you said in (theta, phi) global spherical coordinates.
but where do you then store the actual local measurement values for U and V? will they go into the position's X and Y? and what happens to the Z component?
There was a problem hiding this comment.
Agreed, the documentation needs to be cleaned up and extended.
Not sure I understand your comment about local uncertainties and their correlation being dropped. There should be none - at least that is what is assumed here.
There was a problem hiding this comment.
You can recover the off-diagonal covariance entries from the global position and global covariance (as well as du,dv I suppose), but they're not directly stored (while du,dv are). That was all.
There was a problem hiding this comment.
as I understand it du and dv is basically the pixel size in each direction? so basically just a property of the module. covariance comes into play after we actually measure something
initially I thought you would store global and local coordinates. but actually there are only global coords and the information required to turn them into local coords, right? I just wondered why this is duplicated of each measurement instead of relying on a geometry definition like DD4hep (or DDRec? not sure) or having a surface object in EDM4hep where you can point to with a relation.
the LCIO doc is much better. I guess it can be just copied over. especially the "x-y plane" and "z axis" thing confused me a lot in the current doc in EDM4hep
There was a problem hiding this comment.
Ah, I actually thought it was the actual diagonal covariance matrix elements of the measurement.
There was a problem hiding this comment.
actually you cannot calculate the local coordinates because it would require the global cartesian coordinates of the origin of the detector module that was hit, right?
updating the doc for
TrackerHitPlaneafter clarifying the meaning ofuandv