Reconstruction WG Meeting Minutes
May 7th, 2024
03:30 - 04:30 PM EDT
=================================


Introduction and S&C Workshop Summary
Derek Anderson, Shujie linker
=====================================
  - Announcements:
    - Moving to weekly meeting schedule for next 1 ~ 2 months to accomodate
      extra discussion and make sure progress on various tasks are being
      reported
    - Looking for volunteer with User Learning WG on behalf of Reco WG. Please
      let us know by Friday (May 10th) if you would like to volunteer!
  - Workshop summary
    - Link to agenda is in slides: lots of discussion at workshop!
    - High priority items include ongoing calo/tracking TDR tasks,
      testing timeframes in reco, and validating the reco workflow
    - Will be focusing on improving WG engagement with the FF/FB and
      PID groups, and bringing in more people from DSCs


Tracking EDM Discussion
Wouter Deconinck
=======================
  - Current flow of data:
      SimTracker --> RawTrackerHit
                 --> TrackerHit
                 --> TrackParameters + Measurement2D
                 --> Trajectories + ConstTrackContainer + CKFTrack
  - The kicker is that we can't go back from edm4eic::TrackSegment to
    ActsExamples::{Trajectories, ConstTrackContainer} b/c there's no way to
    make a relation b/n a PODIO object and a non-PODIO object. So we need to
    remove the ACTS types.
  - On top of that there are several redundant copy steps, which is decidedly
    NOT performant.

----------

Dima
  - IndexSourceLink is the ACTS version of relations, right? So can we just
    create PODIO version of the ACTS containers? And is this possible?
Wouter
  - Correct, and it is possible. That's exactly where we want to go: we should
    avoid doing these deep copies
  - The 1st leg of the workflow (with the source linker) is an easy transition,
    but the 2nd (with the trajectories) is the real challenge

----------

  - The ACTS types are quite simple, and the track container is templated in such
    a way that we just need to make an edm4eic type that satisfies the concept
    TrackContainerBackend. But that's not so easy to do...
  - ACTS actually has PODIO interfaces already: the ActsPodioEdm::Track and TrackState
    types
    - Philosophy is a bit different than our current workflow, but has useful info
      that we should consider (e.g. storing ACTS surfaces)
  - H/e there has to be a layer between the PODIO interface and the actual 
    ACTS machinery
    - It's BIG, but at the end of the day we would just need to provide a edm4eic type 
      that gets passed through the layer and then ACTS handles all of the propagation
    - We just need to make sure that our edm4eic type satisfies the previously mentioned
      concept
  - So can we use the ActsPodioEdm?
    - Yes: it's already installed in eic-shell and is avaiable in plugins
    - But it still doesn't work with edm4eic, so we would still need to copy back and
      forth from edm4eic and ActsPodioEdm
  - One thing that was discussed at the workshop w/ the ACTS folks was to modify
    PodioTrackContainer so that it can work with an edm4eic::Track object
  - So Short term plans:
    - Avoid copying into ActsExamples for measurements + track parameters
      (and not duplicating ActsPodioEdm)
    - Create a local copy of the ActsPodio plugin for development, house it in
      our codebase for development with the plan of upstreaming it to ACTS base

Discussion
----------

Dima
  - Not necessarily for this, but these are short term plans. We should
    add another item to this list: we still don't have proper associations
    for the tracker hits
Wouter
  - These enable that
Dima
  - From what I understand this still doesn't allow for new analysis
    chains
Wouter
  - It does, though
Dima
  - My point is that several pieces of development rely on tracks,
    so we need to get functionality in soon that will be stable
Wouter
  - Yes: we can hack together relations between Trajectory and measurements
    pretty quickly
Dima
  - So can we have an implementation with the EDM we already have?
Wouter
  - Yes: I think we can do this now.
Shujie
  - I'm confused: don't we already have that? I think the only thing
    missing is now the connection to measurement and outliers
  - We have the structures there, we just need to add outliers
Tyler
  - Once we have this, do we need a 1-to-1 relation between
    the track projections to tracks?
Wouter
  - No, because the projections start from ActsExamples, so that
    would need to be changed
  - You can get around this on a local branch, though, by feeding
    the projections the Trajectory + all of the ActsExample info 
    and assuming they're ordered in the same way
Tyler
  - So a general question: what's the long term plan? We need 
    to know the track the projection came from
Wouter
  - Right: and we need to stay in PODIO types
Tyler
  - So the plan would be to change the propagation to use a 
    PODIO type?
Wouter
  - Correct


AOB
====
  - Began to touch on other points from EICrecon Roadmap presented at S&C
    workshop.
  - Discussion primarily focused on JANA2's internal bookkeeping, self-
    reporting, and debugging options
    - e.g. Nathan is working on changes that make reporting what factories/
      algorithms were used were very easy
    - If you have strong opinions about how this is done, please let Nathan
      know!