Meeting #18283

Define a policy for LArSoft art-independent code and repositories

Added by Gianluca Petrillo over 3 years ago. Updated about 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


We need a policy that establishes:
  • which repositories LArSoft provides hosting
  • how they relate to the existing repositories, in terms of content and of dependency
  • in which of them new code should be added, according to the new code functionality
  • in which of them existing art-independent code should be moved

Related issues

Related to LArSoft - Necessary Maintenance #17194: Create a location for art-independent service provider detinfo::DetectorClocksClosed07/17/2017

Blocks LArSoft - Necessary Maintenance #18281: Move dumper algorithms in a art-independent repositoryClosed11/15/2017

Blocks LArSoft - Feature #17177: Add backtracker (LarSoft service) information for the reconstruction-truth matching into GALLERY framework.Closed07/13/2017


#1 Updated by Gianluca Petrillo over 3 years ago

#2 Updated by Gianluca Petrillo over 3 years ago

#3 Updated by Gianluca Petrillo over 3 years ago

  • Blocks Feature #17177: Add backtracker (LarSoft service) information for the reconstruction-truth matching into GALLERY framework. added

#4 Updated by Lynn Garren over 3 years ago

Monday at 3:30 Nov. 20

#5 Updated by Lynn Garren over 3 years ago

  • Status changed from New to Closed

The meeting was held. We determined that there was an immediate need for larsimalg and lardataalg, which now exist.

#6 Updated by Gianluca Petrillo about 3 years ago

The conclusions of the discussion will be turned into some form of documentation.
In the meanwhile, a short summary follows (also integrating some "common sense" predating the meeting).

Requirements from factorisation

The factorisation model prescribes:

  1. "algorithmic" code providing the actual software functionality, as portable as possible and framework-independent
  2. interface between the "algorithmic" and LArSoft code, usually depending on the art framework

Code organisation

The code organisation chosen to accommodate the factorisation model prescriptions includes:

  1. algorithmic code confined in its own repository
  2. interface with LArSoft code in its own repository
  3. as a special category, repositories for LArSoft core code, depending on the art framework

The following text will describe the allocation of an hypothetical reconstruction software suite based on TensorFlow, going with the generic name of RecoTF.

Algorithmic code

The category of algorithmic code includes not only actual algorithms, but any code providing some functionality.
It is required to be framework-independent insofar as its full core functionality can be made available on "any" framework context.
This category includes:
  • LArSoft core code that need to be framework-independent; for example: LArCoreAlg
  • third party code (e.g. the pandora toolkit); for example, pandora SDK, recotf

While it is preferred that a repository of algorithmic code be integrated with LArSoft build system, this is a requirement only for the core software and not for the third party code.

The RecoTF software will include an algorithmic code repository, called recotf. This repository may include code explicitly depending on: They are forbidden from depending on:
  • any specific framework (e.g. art)
  • LArSoft core code (below) that depends on art

These items are in order of decreasing likelihood of being needed. We encourage the use of LArSoft data products (e.g. from lardataobj) as deep in the code as possible and recommend the use of FHiCL as configuration language.

Algorithm-framework interface code

This category includes code to enable the use of algorithmic code (above) into a specific framework.
This category includes:
  • interfaces to third party code (e.g. the pandora toolkit); for example, LArPandora, larrecotf

The code must blend in with LArSoft build system and environment (cetbuildtools, mrb).

The RecoTF software will include algorithm-framework interface code repositories; for example, larrecotf (to art framework and LArSoft toolkit), wcrecotf (to a WireCell framework) etc. Of course, we prescribe only on larrecotf, which needs to depend on:
  • the algorithmic code repository recotf; there should be no need of explicit dependency on additional external libraries not already pulled in by recotf
  • the CET build system
  • usually the art framework, in the common case where a run-time plug-in system is needed (modules, services, tools)
  • LArSoft core code (below)

LArSoft core code

LArSoft already includes a lot of code, with a backbone of core repositories in a dependency chain: LArCore, LArData, LArEvt, LArSim, LArReco, LArAna (in dependency order).
These repositories functionally merge the two categories above. Where factorisation has taken place, each of these repositories has a matching algorithmic code repository. Where factorisation is complete (as for larcore), one of the repositories is fully in the algorithmic code category (LArCoreAlg), and the other is in the algorithm-framework interface category (LArCore1).

The RecoTF software will not entwine with this category: LArSoft users will be able to pull in RecoTF facilities through FHiCL configuration pulling in the run-time plug-ins provided in larrecotf.

1 Repository larcore contains utilities that are art-specific and do not have any art independent scope, e.g. classes to facilitate the creation of art services from service providers. In this sense, larcore is not exclusively an interface repository. That is, a user might want to include larcore functionality even when not needing even indirectly any from larcorealg.

Also available in: Atom PDF