Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update TrackerHitPlane doc #160

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

update TrackerHitPlane doc #160

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions edm4hep.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -329,8 +329,8 @@ datatypes :
- float time //time of the hit.
- float eDep //energy deposited on the hit [GeV].
- float eDepError //error measured on EDep [GeV].
- edm4hep::Vector2f u //measurement direction vector, u lies in the x-y plane
- edm4hep::Vector2f v //measurement direction vector, v is along z
- edm4hep::Vector2f u //measurement direction vector for X in global spherical coordinates with R=1 -> (theta, phi)
- edm4hep::Vector2f v //measurement direction vector for Y in global spherical coordinates with R=1 -> (theta, phi)
- float du //measurement error along the direction
- float dv //measurement error along the direction
- edm4hep::Vector3d position //hit position in [mm].
Comment on lines 334 to 336
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I actually thought it was the actual diagonal covariance matrix elements of the measurement.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Expand Down