feat: RootTrackSummaryWriter can write multiple track collections

[paulgessinger]

--- END COMMIT MESSAGE ---

Any further description goes here, @-mentions are ok here!

• Use a conventional commits prefix: quick summary
  • We mostly use feat, fix, refactor, docs, chore and build types.
• A milestone will be assigned by one of the maintainers

[andiwand]

Alternatives would be to schedule multiple writers or merge the tracks before writing - what is the use case here?

[github-actions]

📊: Physics performance monitoring for 94058eb

Full contents

physmon summary

• ✅ Particles fatras
• ✅ Particles geant4
• ✅ Particles ttbar
• ✅ Vertices ttbar
• 🔴 Truth tracking (KF)
• 🔴 Truth tracking (GSF)
• 🔴 Truth tracking (GX2F)
• 🔴 Truth tracking (KF refit)
• 🔴 Truth tracking (GSF refit)
• 🔴 CKF finding performance | trackfinding | single muon | truth smeared seeding
• 🔴 CKF fitting performance | trackfinding | single muon | truth smeared seeding
• 🔴 CKF track summary | trackfinding | single muon | truth smeared seeding
• 🔴 Seeding trackfinding | single muon | truth estimated seeding
• 🔴 CKF finding performance | trackfinding | single muon | truth estimated seeding
• 🔴 CKF fitting performance | trackfinding | single muon | truth estimated seeding
• 🔴 CKF track summary | trackfinding | single muon | truth estimated seeding
• 🔴 Seeding trackfinding | single muon | default seeding
• 🔴 CKF finding performance | trackfinding | single muon | default seeding
• 🔴 CKF fitting performance | trackfinding | single muon | default seeding
• 🔴 CKF track summary | trackfinding | single muon | default seeding
• 🔴 Seeding trackfinding | single muon | orthogonal seeding
• 🔴 CKF finding performance | trackfinding | single muon | orthogonal seeding
• 🔴 CKF fitting performance | trackfinding | single muon | orthogonal seeding
• 🔴 CKF track summary | trackfinding | single muon | orthogonal seeding
• 🔴 Seeding trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 CKF finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 CKF fitting performance | trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 CKF track summary | trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 Ambisolver finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 IVF notime | trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 AMVF gauss notime | trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 AMVF grid time | trackfinding | 4 muon x 50 vertices | default seeding
• 🔴 Seeding trackfinding | ttbar with 200 pileup | default seeding
• 🔴 CKF finding performance | trackfinding | ttbar with 200 pileup | default seeding
• 🔴 CKF fitting performance | trackfinding | ttbar with 200 pileup | default seeding
• 🔴 CKF track summary | trackfinding | ttbar with 200 pileup | default seeding
• 🔴 Ambisolver finding performance | trackfinding | ttbar with 200 pileup | default seeding
• 🔴 ML Ambisolver | trackfinding | ttbar with 200 pileup | default seeding
• 🔴 AMVF gauss notime | trackfinding | ttbar with 200 pileup | default seeding
• 🔴 AMVF grid time | trackfinding | ttbar with 200 pileup | default seeding
• 🔵️ Comparison - Truth tracking (GX2F vs KF)

[paulgessinger]

@andiwand the use case is that for the summer student project I'd like to be able to have the same particles reconstructed under different hypothesis and produce a single TTree. Alternatives would be to add an algorithm that can merge track containers I guess.

Would you prefer that? In the end I don't think the changes are overly disruptive, but I can also keep them private for the summer student project.

[andiwand]

My main concern is that we add more and more targeted features to the writers which tend to break over time and mix with other features. Especially dealing with N inputs and outputs seems like something that can be avoided and generalized to reduce them to their main function.

Maybe a silly suggestion but would multiple writers and hadd also do it?

If you think this has a broader use beyond the project I am happy to get this in.

[paulgessinger]

My main concern is that we add more and more targeted features to the writers which tend to break over time and mix with other features. Especially dealing with N inputs and outputs seems like something that can be avoided and generalized to reduce them to their main function.

True. I guess the problem is we don't have a place to put these changes / features anywhere else. I think keeping them on private branches has the downside that some things are lost unintentionally. I don't really see a lot of harm in this case since the change is a generalization of the functionality we had before.

I think a separate algorithm for merging track containers could alleviate your concerns maybe?

Maybe a silly suggestion but would multiple writers and hadd also do it?

I think with hadd the tracks then end up in separate events, as the tree uses events as entries.

[andiwand]

Ah true our TTrees are not easy to merge...

I agree with you. I believe a merging algorithm would be the most generic solution but we can also refactor this afterwards and go ahead with this one first.