You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 17, 2023. It is now read-only.
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...
The text was updated successfully, but these errors were encountered:
When using edm4hep input the
MCParticles
collection already exists in edm4hep. Therefore, in the conversion from lcio to edm4hepgetCollection()
is not called for this collection. When now converting theRecoMCTruthLink
collection, the lcioMCParticles
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 eitherPodioOutput
crashes complaining aboutor silently writes out garbage
collectionID
andindex
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 theEfficientMCParticles
orInefficientMCParticles
collections created by the CLIC reconstruction. The latter can probably be fixed by limitingm_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...
The text was updated successfully, but these errors were encountered: