Define a policy for LArSoft art-independent code and repositories
- 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
#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:
- "algorithmic" code providing the actual software functionality, as portable as possible and framework-independent
- interface between the "algorithmic" and LArSoft code, usually depending on the art framework
The code organisation chosen to accommodate the factorisation model prescriptions includes:
- algorithmic code confined in its own repository
- interface with LArSoft code in its own repository
- 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,
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:
- the "external" libraries it needs (e.g. TensorFlow)
- the CET build system (cetbuildtools CMake macros)
- code from any LArSoft algorithmic repository it needs (e.g. LArDataObj, LArCoreAlg, ...)
- the CET infrastructure (fhicl-cpp, messagefacility)
- the canvas libraries
- 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(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
- 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.
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