Add an initial particle flow implementation

[therwig]

This PR aims to implement a skeleton of the necessary requirements to perform particle reconstruction across multiple sub-systems. Currently, this considers (truth) tracks, and clusters in each of the Ecal and Hcal subsystems.

The PR is related to updates to the ECal and HCal submodules in order to utilize a common CaloCluster base-class: https://github.com/LDMX-Software/Ecal/pull/53 https://github.com/LDMX-Software/Hcal/pull/65

Performance was shown in past eN and weekly meetings including an overview talk by Jason Wu (a summer intern at FNAL in '23) presented at the end of his program here: https://docs.google.com/presentation/d/18yqZ_82kGT8PvL1rOExaX4xFmR0oYgylV1ESbV1pXSE/edit?usp=sharing

Submodule PRs

• https://github.com/LDMX-Software/Hcal/pull/65
• https://github.com/LDMX-Software/Ecal/pull/53

[therwig]

Thanks Tamas, I believe that I'm happy with all of your suggestions -- will implement them and ping back here.

[therwig]

OK @tvami , I believe I've made all of the changes that you've requested now. I checked that things run with a clean compile from source and generated a cocktail of 1000 events (cocktail of random e/pi/mu/p/n), seeing no failures.

[tomeichlersmith]

The Ecal changes have been merged and included in v0.2.8, please do

cd Ecal
git fetch --tags
git checkout v0.2.8
cd ..
git add Ecal
git commit -m "Ecal on v0.2.8"

[tvami]

There seems to be a merge conflict now:

[therwig]

Hmm, I see it too but I'm not sure what the conflict actually is. I was just following Tom's instructions! 😬

[tomeichlersmith]

(This is a rebase conflict and not a merge conflict. I like doing rebase since it keeps the commit history clean and linear, but it tends to generate more conflicts since it is attempting to re-apply all commits from your history back onto trunk. In general, this is solved by git rebase trunk after pulling the latest trunk, but then you'd have to resolve the conflicts. Testing locally, I can git merge trunk without any conflicts.)

I am willing to drop my personal rebase preference in this case since it is a new addition anyways. I can manually do a git merge locally instead of having GitHub attempt a git rebase merge on their servers.

[tomeichlersmith]

For anyone interested, locally, I am doing what GitHub does on their servers after the merge button has been pressed.

# make sure trunk is up to date
git switch trunk
git pull origin trunk
# make sure dev branch is up to date
git switch pfReco
git pull origin pfReco
git merge trunk
# merge dev branch into trunk
git switch trunk
git merge pfReco
# push to GitHub
git push origin trunk

To add some extra cool-ness, I do not need to click a button saying this PR was merged. GitHub detects that the branch was merged and will mark this PR merged for me. :sunglasses: