Feedback on Helix Algorithm & Type Proposal
Derek Anderson
09.20.2025
-------------------------------------------

- Algorithm Proposal (slides 2 - 4)
  - I like the direction this is heading!
  - Would suggest opening PR sooner rather
    than later
    - Good way to continue discussion while
      development progresses!
- Datatype Proposal (slides 5)
  - To me, looks like the big things this
    new type would add are:
    (1) explicit parent/daughter relations
    (2) parent/daughter kinematic info
    (3) geometric info
  - Some concerns:
    - New type would be *hefty* (lots of
      fields)
    - Additional fields duplicate info that
      could/is stored in existing types (see
      below)
  - Suggestions:
    (1) Parent/daughter relations and
        kinematic info should be encoded in
        ReconstructedParticle::particles
        and ReconstructedParticle::{momentum,
        energy} fields
        - Current practice: for a resonance,
          calling getParticles() returns
          its decay products
        - See the FF lambda reco Algorithm
          for a good example:

https://github.com/eic/EICrecon/blob/main/src/algorithms/reco/FarForwardLambdaReconstruction.cc

        --> Following this Would avoid need
            to explicitly identify parent/daughters
            relations in vertex type
    (2) Can use ReconstructedPartcile::{referencePoint,
        startVertex} fields to store a resonance's 
        decay vertex and production vertex respectively
        - eg. 0 = primary, 1 = secondary, etc.
    (3) Should use existing edm4eic::Vertex::particles
        fields to identify particles attached to vertex
        - eg. calling getParticles() on a secondary vertex
          would return parent + daughters
        - Then could use particles' getParticles() to 
          identify parent/daughters
    (4) Encoding geometric info is tricky... Could take 
        a couple approaches
        (A) Add some short helper functions to edm4eic::utilities
            to calculate DCA, theta, L, etc. using provided 
            vertices
        (B) Or could define a type that stores only the 
            geometric info for a particle relative to a vertex
  - Suggest opening issue on EDM4eic Github with proposed 
    type to refine proposal