REST-for-Physics
v2.3
Rare Event Searches ToolKit for Physics
|
The REST-for-Physics (Rare Event Searches Toolkit) Framework is mainly written in C++ and it is fully integrated with ROOT I/O interface. REST was initially born as a collaborative software effort to provide common tools for acquisition, simulation, and data analysis of gaseous Time Projection Chambers (TPCs). However, the framework is already extending its usage to be non-exclusive of detector data analysis. The possibilities of the framework are provided by the different libraries and packages written for REST in our community.
The REST Framework provides 3 interfaces that prototype the use of event types, metadata and event processes through TRestEvent
, TRestMetadata
and TRestEventProcess
abstract class definitions. Any REST library will implement specific objects that inherit from those 3 basic interfaces.
Different event processes can be combined to build complex event processing chains with full traceability. The metadata objects will allow us to provide input parameters or information to the framework using a XML-like format. REST integrates a special metadata object named TRestManager
that encapsulates all the required information to launch the processing of a particular data chain. REST will produce output using ROOT format. Any REST file will always contain a TRestRun
metadata object. TRestRun
is a metadata object responsible to encapsulate and give access to all the objects stored inside the REST/ROOT file; i.e. the specific resulting TRestEvent
output, the TRestAnalysisTree
, and any specific TRestMetadata
object used during a processing chain.
This framework provides additionally different interfaces to browse data, TRestBrowser
, event visualization TRestEventViewer
, define a event data processing infraestructure, TRestProcessRunner
, event analysis and metadata plotting, TRestAnalysisPlot
or TRestMetadataPlot
, a common access analysis tree based on TTree
ROOT object, TRestAnalysisTree
, and centralizing the use of REST through a manager TRestManager
are few of the features the framework offers when used standalone.
Other objects included in the framework will help to add unit definitions, REST_Units
, define physical constants and basic physical routines, REST_Physics
or access to geometrical calculations, TRestMesh
. Additional objects provide methods to help on text formatting as TRestStringHelper
or define output styles, TRestStringOutput
.
Basic pure analysis tasks will also be included in this framework, such as a processes performing fundamental routines, such as performing generic fits on observables/branches found inside the analysis tree, producing a summary report, creating data quality rules definitions, or basic interfaces to external databases.
REST is mirrored to the following repositories where pipelines are executed, and where code can also be retrieved.
Code can be pulled for read-access from those mirrors, however, development is centralized at the main GitHub public repository.
Please, visit the REST-for-Physics userguide for installation instructions.
Please read CONTRIBUTING.md to get some guidelines on how to contribute to this project. Before any contribution, those guidelines must be assimilated and accepted. In any case, changes, improvements, or addons, to CONTRIBUTING.md are aceptable after proposal and discussion with other authors at the REST Framework forum.
The framework exploits the Git tagging system to produce its own versioning system. It is important to emphasize that the REST framework centralizes the versioning of all the submodules (libraries, packages, ...) that it contains. Details on how the REST version number is produced are given in CONTRIBUTING.md.
Any metadata object written with REST will be stamped with few metadata members that will allow to identify the state of the code when the object was produced. Those data members are:
source clean-state.sh
at the project root.If different REST versions were used to write a ROOT file, e.g. at different steps of the data processing chain, the historic metadata objects will preserve their original version. However, the TRestRun
metadata object will always store the version used to write the ROOT file.
After REST release 2.2.1., REST implements correctly the ROOT schema evolution
. Therefore, any new REST version should always be backwards compatible. I.e. Any file written after v2.2.1 should be readable without problems with any future version.
A major change at 2.3 will prevent from backwards compatibility, since class names have been reviewed.
This project is licensed under the GNU License - see the [LICENSE](LICENCE) file for details
We acknowledge support from the the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme, grant agreement ERC-2017-AdG788781 (IAXO+), and from the Spanish Agencia Estatal de Investigacion under grant FPA2016-76978-C3-1-P