Closed doloresgarcia closed 4 weeks ago
I would suspect this check
Still need to figure out why it fails though, maybe something in the translation mappings has changed unexpectedly recently @tmadlener?
When did it start failing? My suspicion would be that it's an issue related to TrackerHitPlane
vs TrackerHit
in the filling of the association. We have removed the association from TrackerHitPlane
to SimTrackerHit
in EDM4hep (https://github.com/key4hep/EDM4hep/pull/331). The corresponding changes in the converter are: https://github.com/key4hep/k4EDM4hep2LcioConv/pull/73 and https://github.com/key4hep/k4EDM4hep2LcioConv/pull/76
I think I found one suspicious bit but I don't think that it was the source of this error https://github.com/key4hep/k4EDM4hep2LcioConv/pull/83
As there are still associations created but just default initialised (which I would think from the -2) this check should not have been the problem.
Does it maybe just not work because the typeMapping.trackerHits
that is also passed for TrackerHitPlanes contains a mapping to TrackerHit3D and not to the TrackerHit interface? I think that would fit with the above error :)
Does it maybe just not work because the typeMapping.trackerHits that is also passed for TrackerHitPlanes contains a mapping to TrackerHit3D and not to the TrackerHit interface? I think that would fit with the above error :)
indeed
using the nightlies, the last CLDConfig and CLD_o2_v06,
VXDTrackerHitRelations
(as well as other relation collections for the tracker hits) rec and sim index are filled with -2san example file can be found here:
/eos/experiment/fcc/ee/datasets/CLD_tracking/condor/Pythia_eval/Zcard_CLD_v3/1/out_reco_edm4hep_edm4hep.root