PDG field in ReconstructedParticle is desirable in EIC workflows

[wdconinc]

EIC physics analysis does not commonly use particle collections such as ReconstructedElectrons or ReconstructedMuons, where the pdg code is obvious by the choice of collection. This is because separation between different particle identification assumptions is often analysis depenedent and not as clearly separate. For this reason, ReconstructedParticles is likely an end-point in most EIC analysis chains, from where to first order the most likely pdg code is used. Since currently there is no easy way to use numpy with relations, we (EIC) are left without an easily accessible pdg id for a large fraction of our physics analyses, and we have locally added a pdg field.

E.g. https://github.com/key4hep/EDM4hep/blob/master/edm4hep.yaml#L386

      ##@TODO: deviation from EDM4hep: store explicit PDG ID here. Needs to be discussed how we
      ##       move forward as this could easiliy become unwieldy without this information here.
      ##       The only acceptable alternative would be to store reconstructed identified 
      ##       particles in separate collections for the different particle types (which would
      ##       require some algorithmic changes but might work. Doing both might even make
      ##       sense. Needs some discussion, note that PID is more emphasized in NP than
      ##       HEP).
      - int32_t           PDG               // PDG code for this particle

Opening this issue here as a starting point for discussion.

[andresailer]

I think de-facto we are using the type field for this PDG information.

See
https://github.com/iLCSoft/DDMarlinPandora/blob/9dcf11e92c6426e334bdd6d3566079e335d99ed8/src/DDPfoCreator.cc#L415
Where this is filled from the Particle Flow algorithm (and later converted to EDM4hep
https://github.com/key4hep/k4LCIOReader/blob/cd2280be18c47182e23c2a090bd1e626125d6984/k4LCIOReader/src/k4LCIOConverter.cc#L726

[tmadlener]

As discussed during the meeting today (minutes). We consider renaming type into PDG as that seems to be the primary (only?) use case. We will have to check

• Check if there is code that uses type differently
• Make sure we can do this without schema evolution ready yet. This should be possible since the layout of ReconstructedParticleData does not change.

[wdconinc]

In the EIC reconstruction software we do not use type in any other way, so this would be ok with us.

[tmadlener]

I have done a few search queries via github for some of the organizations that would most likely be affected by this:

• key4hep: getType, setType
• HEP-FCC: getType, setType
• cepc getType, setType

It looks like there is no other use case than as PDG code. (Note that there is quite some noise in these queries as [s|g]etType is quite frequent also for other types and use cases).

[andresailer]

• Think about renaming type to PDG
  • Check usage first
  • Schema evolution necessary?
• What happens, e.g. for Jets?
  • not setting type https://github.com/iLCSoft/MarlinFastJet/blob/4bee01f859c26b7faee90317947b9d8ee2e5c373/include/FastJetUtil.h#L556-L577