Structural changes to SpectrumLoader & friends to admit one-to-many (SR -> SRNeutrinoInteraction) analysis over new CAF structure

[chenel]

The v3 duneanaobj structure, in which each StandardRecord corresponds to the reconstructed information from a single detector trigger, is difficult to handle with the current approach in CAFAna. In particular, users will almost always want to run their primary analysis over SRNeutrinoInteraction objects, which (with the current tools) require a lot of MultiVar constructions and make for difficult use of Cuts.

A path forward for handling this more naturally is to opt-in more wholeheartedly to the Source-Sink architecture in CAFAnaCore v2. SBN's implementation of CAFAna has a PR where this is done concretely: https://github.com/SBNSoftware/sbnana/pull/85. We could cherry-pick some of the work there and adapt for DUNE CAFAna, which would build upon, but significantly extend, the work in #46.

• [x] Update SpectrumLoader to become an _ISource via inheritance through Passthrough<StandardRecord>
• [ ] Create explicit instantiations of the _IRecordSource interface:
  • [x] For StandardRecord (called IStandardRecordSource, or perhaps ISRSource) with VectorAdapter<SRInteraction> objects in the same spirit as the SBN case
  • [x] For SRInteraction, with VectorAdapter<SRRecoParticle> (and any other subfields as necessary)
  • [ ] Perhaps for SRNDLAr or other detector-specific cases? (To be added as needed.)
  • [ ] Add vector adapters from reco to true branches
  • [x] Demonstration/test macro plotting a simple physics quantity using the new infrastructure. Maybe reco muon energies within selected numu candidates?

This issue would only get us halfway to a functional replacement for the current CAFAna, since the current code that handles systematic shifts would need to get offloaded out of SpectrumLoader, but would result in a functional system for creating "central value" Spectrums. The remaining work is detailed in #53.

[mcasales]

I merged this branch with my branch feature/mcasales_CAFAna_2x2. A lot of code is messily commented out (but it works!). I decided to clean that up later, when this branch compiles and runs. I think I implemented the SpectrumLoader/SpectrumLoaderBase similar to SBN CAFAna. (See commit ) I am not sure if the VectorAdapter from SRInteraction to SRRecoParticle will work as we want, I embedded dlp in the reco particle adapter. We discussed we might not want different adapters for deep-learning/pandora, but I don't see how to avoid that at the moment.

[mcasales]

First attempt to compile miserably failed (as expected ) . I think we also need to take a look at Loaders which are a Sources<SpectrumLoader>. ??

[mcasales]

Did some fixing of Loaders Var Cut, which are used for the OscillatableSpectrum. This does not compile yet, I have yet to understand this errors at CAFAnaCore level such as :

/cvmfs/dune.opensciencegrid.org/products/dune/cafanacore/v02.00/include/CAFAna/Core/Weighter.h:12:59: error: expected template-name before ‘<’ token
   12 |   template<class RecT> class _Weighter: public Passthrough<RecT>, protected EnsureFiniteBase
      |                                                           ^
/cvmfs/dune.opensciencegrid.org/products/dune/cafanacore/v02.00/include/CAFAna/Core/Weighter.h:12:59: error: expected ‘{’ before ‘<’ token
make[2]: *** [Core/CMakeFiles/CAFAnaCore.dir/Loaders.cxx.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/dune/app/users/mcasales/CAFAna-rebuild/lblpwgtools/CAFAna/Core/OscillatableSpectrum.cxx: In lambda function:
/dune/app/users/mcasales/CAFAna-rebuild/lblpwgtools/CAFAna/Core/OscillatableSpectrum.cxx:29:34: error: use of deleted function ‘caf::Proxy<caf::SRNeutrinoEnergyBranch>::Proxy(const caf::Proxy<caf::SRNeutrinoEnergyBranch>&)’
   29 |                      return ixn->Enu;
      |                                  ^~~

``` `
But that's it for today.

[mcasales]

I added more tasks in the second bullet. We need to address the remaining vector adapters to connect true and reco branches.