LArSoft

Since the requester is in MicroBooNE, it should be noted that in order for MicroBooNE to be able to effectively use BackTracker, MicroBooNE must also make its geometry and its DetectorClocks implementation of choice be available in that context.

Lynn, what work by Hans are you referring too? I would be interested in having a look at it.

Additionally, I am fairly comfortable with the NuTools/BackTracker dependencies, and would be able to elaborate with a more specific question.

Katherine, This issue has been assigned to me, what about the sub issues (The issues blocking this issue.) Will those also be delegated to me?

Hans Wenzel is rewriting LArG4. To the best of my knowledge, none of that work is available yet. General outlines have been presented at various coordination meetings. It is possible that the work Hans is doing will make the nutools geant4 interface unnecessary. Please contact Hans directly.

Jason Stock wrote:

Katherine, This issue has been assigned to me, what about the sub issues (The issues blocking this issue.) Will those also be delegated to me?

(non-Katherine here)

Not necessary. LArSoft, owner of repository structure, should suggest where to put both the services in issue #17179 and this one (they may be two different places, too).
After that, the resolution of issue #17179 should be quick: differently from chet::BackTracker, detinfo::DetectorClocksStandard is already Gallery-ready.

So, this is now going to be related to the introduction of the ParticleInventoryService. The new ParticleInventory will be ready for Gallery, and the BackTracker/PhotonBacktracker will be rebuilt to use the ParticleInventory. At the same time I will try to make them Gallery ready.

Design decision time.

Functions have been added to the backtracker that take a trackID, and return all hits from the TrackID. While this is a potentially very useful function, it takes as an input a list of candidate hits that it is supposed to search for the Hits associated with TrackID X. I do not like this design for cases where the user wants to search all hits. Is there a serviceprovider or tool in LArSoft already to quickly access all hits in an event, or will I need to script one into the backtracker?

Are you asking whether LArSoft has a standard way to allow an experiment to specify which hit collection to use "by default"?
The current answer is no, and while there are vague talks of that changing, I believe this is not going to happen any time soon.
In case, that collection might even be a collection of art pointers rather than a collection of hits, to allow mixing different collections without data duplication and information loss.

Thank you Gianluca. I will go ahead and write a template in the backtracker to get all art::Ptr to recob::Hit objects out of the event. We can change that in the future to conform to whatever LArSoft decides to do later.

Many of the backtracker functions have been changed to optimize the work done, reduce memory usage, or try and build a self-consistent interface. These changes are still restricted to my feature branch for the backtracker. Before deployment, feature branches for all larsoft code will be needed to update calls to the backtracker.

I will mark this resolved with LArSoft v06_56_00. Both ParticleInventoryService and BackTrackerService have art independent service providers.

This didn't make larsoft v06_56_00, but it is now integrated in larsoft v06_58_00. I am marking this as resolved.

I don't appear to be able to close this ticket myself. It has been resolved for some months now with the adoption of the BackTracker/BackTrackerService.