feat: support EDM4hep v0.99, with TrackerHit as interface type

[wdconinc]

Briefly, what does this PR introduce?

EDM4hep v0.99 introduced TrackerHit as an interface type, and the datatype that used to be called TrackerHit is now called TrackerHit3D. We use this in a few places, and this PR disambiguates the TrackerHit datatype. To minimize impact on the code and limit the annoying code effects to the preamble, this defines an alias of the new name.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue: Use interface types for TrackerHit key4hep/EDM4hep#252)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No.

Does this PR change default behavior?

No.

[github-actions]

Capybara summary for PR 1676

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2024-11-20T20:19-05:00 1dbc737}}

[simonge]

I believe it is now possible to use edm4eic tracker hits rather than the edm4hep model, this should fix a couple of other things and avoid unnecessarily having to add this complexity.

[wdconinc]

I believe it is now possible to use edm4eic tracker hits rather than the edm4hep model, this should fix a couple of other things and avoid unnecessarily having to add this complexity.

It seems we have one to one relations to raw hits in edm4eic so it's not a trivial change.

[simonge]

I believe it is now possible to use edm4eic tracker hits rather than the edm4hep model, this should fix a couple of other things and avoid unnecessarily having to add this complexity.

It seems we have one to one relations to raw hits in edm4eic so it's not a trivial change.

Yes, just been looking through the options again now and being reminded of all the subtle changes (in my opinion) need addressing.

The edm4hep TrackerHit has changed significantly in v0.99 from our current version but isn't really what is required either.

[simonge]

Rather than continuing to use the edm4hep version, I would be in favour of adding the Measurement3D to edm4eic where the surface from Measurement2D is replaced by the 3rd spatial dimension and covariance.

Is there no point during the acts tracking procedure where the data is in this format? Every time I try and look through it, I find the acts coding style slightly impenetrable.

[wdconinc]

Rather than continuing to use the edm4hep version, I would be in favour of adding the Measurement3D to edm4eic where the surface from Measurement2D is replaced by the 3rd spatial dimension and covariance.

I think we should try to move closer to EDM4hep where we can, not move further away. I think this makes sense especially for data types that are before typical reconstruction steps such as clustering or tracking. We are already much farther away from EDM4hep than I wish we were.

[simonge]

The problem as usual is keeping associations so that they can be traced through the reconstruction.

The pre-v0.10 version of edm4hep::TrackerHit had this convenient but probably misguided vector of ObjectIDs which allowed a link to any podio object, in this case between the TrackerHit and an edm4eic::RawTrackerHit. At very least this will have to be replaced with a edm4hep::TrackerHitSimTrackerHitLink, linking back to the simulated rather than raw hit through our edm4eic::MCRecoTrackerHitAssociation.

edm4hep v0.99 doesn't appear to have very good support for our approach of converting everything into the raw tracker/calorimeter hits with just digitized time and charge values and no links/relations/associations between them. There is no RawTrackerHit type but admittedly this would just be identical the the RawCalorimeterHit.

Is this the only block from updating to v0.99?