Restructure proposal

Basic details of the proposal

Initial proposal is in MicroBooNE docdb 3456 ( The basic goals are:
  • Code should be separated into three main components:
    • algorithm --- code that performs tasks related to simulation, reconstruction, and analysis;
    • data product --- structures that contain the basic data to be read from and stored, including simulation, reconstruction, analysis, and detector configuration products; and,
    • "framework" --- code that retrieves data from files, runs algorithms, and stores data products into files.
  • Algorithm code should be completely independent of framework elements, depending on
    • LArSoft data products (more on that below)
    • standard C++ elements
    • ROOT data products and functions
    • boost libraries
    • FHICL parameter sets
  • Algorithms should be as "single-purpose" as is reasonable, or contain and run a collection of such "single-purpose" algorithms.
  • Data products should be completely independent of framework elements, depending on standard C++ elements.
  • Included in data product definitions should be a data product version number that can be accessible by frameworks for proper storage.
  • Frameworks must support all elements of LArSoft algorithms and data products.
  • Frameworks should require no modification of LArSoft algorithms or data products. If needed, framework code should include simple wrapper elements to provide necessary functionality for data products or algorithms, but such wrapper elements should not alter the behavior of data products or algorithms.
  • Algorithm, data product, and framework code should exist in separate repositories.

Known issues that require more thought/consensus

  • Do we need a BaseAlg class?
    • Consensus seems to be leaning towards 'no', but details of the test framework will inform this.
  • What do we do about associations?
    • Options are to (1) leave associations to the frameworks, but establish a simple association-making interface that all algorithms may share, or (2) write our own association data product, that is used in place of any framework association product.
  • What are the proper models for sending in "service products"?
    • Options are to (1) pass in by reference, as with data products, or (2) pass in const pointers. Both options should be explored, and perhaps both may be used.
    • Depending on the details of ART, services may need to be provided on a per-event basis. This probably necessitates configuration of algorithms that is independent of service products, with an additional "loadservices" or "configureservices" function that can be called per event.
  • What do we do with the TFileService?
    • Is there a clean way for algorithms to return ROOT objects that can be used by ART's TFileService?
  • MessageFacility
    • Do we require that the message facility be supported by all frameworks, or do we drift away from using it in algorithms?

Tasks for carrying out the restructuring

Data products

  • All simulation, reconstruction, and analysis data products must be made to be ART-independent
  • Those data products must also have their private and public elements split, in order to avoid needing the GCCXML def in the files. ART and other frameworks that need them should make simple wrappers to include them.
    • RecoBase
      • Hit: art::Ptr to recob::Wire and raw::RawDigit should be removed
      • Wire: art::Ptr to raw::RawDigit should be removed
    • RecoObjects
      • BezierTrack: art::PtrVector to Hits should be reformulated
      • KGTrack: functions using art::PtrVector to Hits should be reformulated
      • KHitContainerWireX: functions using art::PtrVector to Hits should be reformulated
      • KHitWireX: art::Ptr to recob::Hit should be removed or reformulated
    • AnalysisAlg
      • CalorimetryAlg: use of art::Ptr to Hit should be reformulated, and ServiceHandle elements should be removed/reformulated
      • Chi2PIDAlg: use of art::Ptr to Calorimetry object should be reformulated
    • Simulation
      • (??? Needs to be determined)
  • Class versioning definitions independent of ART/ROOT should be written, and wrappers to take those definitions and put them in framework should be written.
  • All non-framework services (geometry, detector propoerties, etc.) should have a corresponding data product that is ART-independent.
  • Simple wrappers for providing these "service products" as services in ART need to be written.
  • lardata/Utilities needs to be analyzed, deciding which elements need to be framework independent, and which belong to the ART framework


  • A BaseAlg class, if decided upon, should serve as the base for all algorithms.
  • All modules need to be reviewed, with all "algorithm" work placed into self-consistent algorithms, following guidelines above.
  • All algorithms need to have ART-independent inputs.
  • All algorithms need to have service handles removed from them, with service products passed in by reference/pointer.

Code Structure

  • Algorithms and data products should be moved to their own repositories