Change the default output name for the reco - mc links

[tmadlener]

Currently the default output name in the example for the link between Reco and MC particles is slightly misleading regarding the direction of the link. Following the EDM4hep naming convention the name suggests that MC is from and reco is to, when in fact the RecoMCParticleLink defines them in the opposite way.

k4SimDelphes/examples/edm4hep_output_config.tcl

Line 12 in c79aaf7

set RecoMCParticleLinkCollectionName MCRecoAssociations

• We have to make sure that changing the example here doesn't break any production

@BrieucF just FYI

[tmadlener]

@kjvbrt also as a heads up, following this change for FCC would break FCCAnalyses quite heavily, I think.

[bistapf]

I think only the datasource version of FCCAnalyses explicitly uses the link, while the old style still does the manual index hopping anyway - or am I mistaken, @kjvbrt ? E.g. code that relies on it: https://github.com/HEP-FCC/FCCAnalyses/blob/b9b84221837da8868158f5592b48a9af69f0f6e3/analyzers/dataframe/src/ReconstructedParticleSource.cc#L22

Since we have started a production for FCC-hh recently it wouldn't be super ideal to make this renaming. However we don't currently use the links for FCC-hh analyses, but once this is propagated to a release, will files produced with an older version before the name change still be readable as long as the RecoMCParticleLink is not used?

Given that the FCC-hh production currently relies on nightlies at this stage (mainly due to #136) things are a bit complicated though. I think it may be fine to change the name, but then as soon as possible, so it's in the next stable release that would officially be used for the production then. If files pre-namechange become unreadable then though, it would mean reproducing some samples for FCC-hh.

[BrieucF]

Thanks @tmadlener for opening the issue and @bistapf for checking already the impact it would have.

I also checked whether there were other definitions of EDM4HepOutput in FCC-Config (there is none). In EventProducer, there is nevertheless the possibility to use a custom EDM4HepOutput tcl file: EventProducer.

I will investigate further and let you know

[BrieucF]

Edit to the above: there is one in FCC-config (https://github.com/HEP-FCC/FCC-config/blob/winter2023/FCCee/Delphes/edm4hep_IDEA.tcl) but it is in the winter2023 branch which is used with a fixed stable release using the 'old' associations. Everything is fine in this regard.

So the last word goes to you @bistapf !

[kjvbrt]

Hi, the change will affect mostly user code (analysis scripts) not really any production code and it does not matter if users use FCCAnalyses with datasource or not.
As long as the name is consistent among the samples in the campaign, this should be fine.

[BrieucF]

Thanks Juraj, @bistapf, can we proceed?

[bistapf]

Hi @BrieucF, all. Thanks a lot for the follow-up. Given that for FCC-hh I actually do use a custom edm4hep output config file already, I think there isn't any technial issue from my side. For the record, we agreed for now to keep the old name in the FCC-hh v06 production, and once we move to a new production we will update the name also.

TL,DR: Yes, please go ahead and merge.

[jmcarcell]

What about this line?

k4SimDelphes/framework/k4SimDelphes/examples/options/edm4hep_output_config.tcl

Line 11 in a3c5b0e

set MCRecoAssociationCollectionName RecoMCLink

Should it also be changed (the part on the left)? There is already a deprecation warning for this name from a few months ago: https://github.com/key4hep/k4SimDelphes/blob/main/converter/include/k4SimDelphes/DelphesEDM4HepOutputConfiguration.h#L156

[tmadlener]

Ah, damnit. Good catch. Didn't even think about that. That should definitely also be fixed. PR in the making.

edit: see #141

[jmcarcell]

What about the warning, should we turn it into an error or keep it there for cards that still use the old name?

[tmadlener]

I would keep it as a warning for now and make it an error after the next tag only.