LDMX-Software
adding more muscles to pflow skeleton
Is your feature request related to a problem? Please describe. The current particle flow code is (in @therwig's own words) a skeleton implementation that is a great proof-of-principle but could (now that the principle has been proven) use some more work on pulling in reconstructed objects from wherever algorithm improvement work has been done.
Describe the solution you'd like That PF is able to take a range of inputs: truth tracks, reco tracks, SP info (for ideal world benchmarking), clusters from ecal and hcal based on different algorithms, including trigger algo objects.
Describe alternatives you've considered Custom processors for any study or use case envisioned where info is combined across detectors.
Additional context This is a discussion issue that will benefit from detailed sub-issues. Some concrete ideas from discussion with @therwig and @EBerzin here: [ ] use real reco tracks in PF producer [ ] set up flexible interfaces to allow for modular tests of different input objects and PF configs [ ] make a nice suite of validation tests for PF to include in the continuous integration workflow (a great way to catch both reco+physics changes!)
Please add thoughts in this thread so we can extend this list and start spawning sub-issues.
In my mind, PF needs to know how to do the stitching between objects at system boundaries. So it makes sense if the actual implementation of particle flow is responsible for knowing where an input collection comes from (e.g. if a cluster belongs to ecal or hcal). But input object collections themselves could actually be of the same type. For example we might only have caloclusters and tracks as our two types of PF input, regardless of ecal/hcal or silicon/TS. The deduction of system comes from setting hcal_clusters = ... etc. This kind of logic immediately makes PF more flexible.
This harmonization could be done either upstream (reconstruction output object type), or in a dedicated processor/functions to translate from specific to general type. I'm not sure why we need simhits in a tracker and a calorimeter to be different types, and same goes for reconstructed hits. I suspect this is a legacy differentiation from back when truth information was used directly in e.g. vetoes: then we needed tracker simhits to carry momentum while calo simhits carried energy. If we could let the detector specifics be contained in the digis, and only there, that would make a lot of sense to me.
It's maybe more work (absolutely a more major decision) but I think it would be a powerful move to have a harmonized, smaller set of output objects. This could be very liberating when it comes to further reconstruction algorithm development.