Remove the colorFlow member from the MCParticle

[tmadlener]

BEGINRELEASENOTES

• Remove the colorFlow member variable from the MCParticle since it is effectively unused (and should remain that way as there is no really correct way to use it without baking in generator specific assumptions).
  • This is a backwards compatible change w.r.t. readability of existing files (ROOT schema evolution handles this)
  • This is a breaking change for the API as {get,set}ColorFlow are removed from the MCParticle.
• Remove the now unused edm4hep::Vector2i from the components

ENDRELEASENOTES

This is a follow up on #237 and another discussion with generator / HepMC3 authors. The only place where colorFlow is used in the iLCSoft / LCIO world is the TrueJet processor. However, also in there it has remained at the idea stage of an implementation, and is not actually used.

Since this is effectively generator internal information and EDM4hep is not the format to exchange data between generators we decided to remove this.

• The edm4hep::Vector2i is effectively only here because of this. Should we also remove it? @wdconinc do you actually use it in EDM4eic somewhere? -> removed
• Needs Remove the colorFlow from the conversion of the MCParticle k4EDM4hep2LcioConv#104 to not break the nightlies
• Needs Remove the color flow from MCParticle HEP-FCC/k4SimGeant4#78 to not break the nightlies
• Needs Remove the colorFlow from the output k4GeneratorsConfig#26 to not break the nightlies
• Needs Don't include Vector2i which is unused HEP-FCC/FCCAnalyses#421 to not break the nightlies
• Needs Do not set or read the color flow for MCParticles from EDM4hep AIDASoft/DD4hep#1374 to not break the nightlies
• Needs Do not set the color flow from MCParticles k4geo#417 to not break the nightlies

[wdconinc]

• do you actually use it in EDM4eic somewhere?

We do not use Vector2i or colorFlow (i.e. we use Vector2i only to set colorFlow to some default value when we have to create MCParticles). We can get rid of it and work around it with preprocessor directives on the podio version.

[tmadlener]

We should (hopefully) also export enough information through the pre-processor for EDM4hep to check on that directly (instead of making a proxy check via podio).

[wdconinc]

We should (hopefully) also export enough information through the pre-processor for EDM4hep to check on that directly (instead of making a proxy check via podio).

Yes, sorry, we do indeed us EDM4HEP_VERSION_MAJOR etc, no need to go through podio (though schema_version could be useful to expose).

[tmadlener]

Ah we don't do that yet via the pre-processor, but it's available as a constexpr static variable.

#include <edm4hep/DatamodelDefinition.h>

if constexpr (edm4hep::meta::schemaVersion > 2) {
  // do something
}

s/edm4hep/your-data-model/g will give you the same for your-data-model in case it is ever needed.

[jmcarcell]

This should be ready, the downstream build https://github.com/key4hep/EDM4hep/actions/runs/12412376830/job/35417731197?pr=389 doesn't show any issues related to this.