search

key4hep / k4LCIOReader

Generate EDM4hep collections from LCIO format data
Apache License 2.0
2 stars 11 forks source link

Broken associations caused by k4LCIOConverter being unaware of already existing edm4hep collections #31

Closed Zehvogel closed 1 year ago

Zehvogel commented 1 year ago

When using edm4hep input the MCParticles collection already exists in edm4hep. Therefore, in the conversion from lcio to edm4hep getCollection() is not called for this collection. When now converting the RecoMCTruthLink collection, the lcio MCParticles collection gets converted temporarily to an edm4hep collection. The entries from this collection are then used as sim particles in the edm4hep association. In the end, when writing the edm4hep output file either PodioOutput crashes complaining about 

[ctest] PodioOutput         FATAL  Standard std::exception is caught 
[ctest] PodioOutput         ERROR Trying to persistify untracked object
[ctest] EventLoopMgr        FATAL .executeEvent(): Standard std::exception thrown by PodioOutput
[ctest] EventLoopMgr        ERROR Trying to persistify untracked object

or silently writes out garbage collectionID and index values for this association. (I have not understood yet which configuration changes between those two)

This does not happen for all particles as there is still another "bug" hiding this. As getCorresponding simply returns the particle from the first collection found in the (alphabetically ordered) m_type2cols map, this problem does not occur for charged particles making it into the EfficientMCParticles or InefficientMCParticles collections created by the CLIC reconstruction. The latter can probably be fixed by limiting m_type2cols to non-subset collections.

I will not have time to try to build a fix for this in the next 2-3 weeks, so if anyone wants to have a go at this...