NA62 FrameWork consists at this time of four packages:
|NA62MC||Geant4 based framework for NA62 detector full simulation (now includes all subdetectors, with their persistency of hits)|
|NA62Reconstruction||Root based reconstruction package, modularized in libraries for individual subdetectors (now includes all subdetectors, at different stages of development). It contains also the online monitor (NA62OnlineMonitor) and a visualization tool (NA62EventDisplay)|
|NA62Analysis||ROOT based framework for modularized development of simple and complex analysis (now including several tools, from detector acceptance definition to candidate particles collecting information from all detectors)|
|NA62DB||Interface library to the offline Oracle metadata database (still experimental)|
There is a significant amount of documentation embedded in the code using doxygen.
NA62 software has been designed trying to keep its complexity as low as possible and yet allowing enough flexibility to accommodate the needed functionality and collaborative development.
The diagram below sketches the data flow from the experiment (grey blocks) to the end user, grouped in the three main software packages and the data storage library. The simulation is kept as much as possible independent from the experimental conditions, offloading most of the time dependent parameterisations to the digitization stage.
The standard units adopted across the whole software are ns, MeV and mm.
Running a precompiled version
Precompiled versions of the packages can be run using a configuration script:
The -h option will show how to use it. It will create a directory with all the necessary files and scripts to be sourced to setu pu the environment. Using rcurrent as VERSION will provide the latest revision available.
Revisions will be made available on request.
This is the preferred method for end-users, i.e. to run analysis only, but it works only if afs is available on your system.
It is recommended to join the mailing list (see link at the top of this page); it is instead necessary to have access to the source code on gitlab.
Development versions are identified by a progressive number (often prepended by "r", e.g. r858), while pre-production and production versions are identified by three progressive numbers (often prepended by "v", e.g. v0.9.0).
We are currently moving from AFS to CVMFS; at the moment only (pre-)production versions are available on CVMFS.
Getting the source code
There is a short set of established rules concerning the coding style:
- Variables and methods names should look like DescriptiveWordsOrSentences
- Persistent object names should start with "T"
- Data members of classes should be named prepending "f" and starting with a capital letter
- Access methods for data members should be named replacing "f" with Get/Set
- Pointers to histogram, graphs and profiles should be named prepending "H", "G" or "P", respectively, to the ROOT name of the object