User

Roles
Anonymous

AliRoot Release Information Page

Contents

Releases

The actual releases available on the GRID can be found in the MonALISA Repository for ALICE.

More extensive information about the all the AliRoot Releases can be found in the AliRoot Git repository.

Code is availaible for all the versions. Please see installation for details on how to get the code. The documentation is also available in the Git distribution.

Release policy

  1. The program librarian announces a new regular release 10 days before the creation of the release branch.
    1. The new code is committed to the Git master branch in “atomic way”: the compilation of the trunk is possible after each commit. This will be enforced. The librarian has the right to revert code that doesn’t compile.
    2. The new code compiles without warnings.
    3. The new code respects the coding conventions.
    4. The backward compatibility of the CDB classes is maintained.
  2. After the creation of the release branch the next 10 days are used for tests and bug fixes. The problems are reported on the Savannah page and attached to the corresponding authors. A copy message is sent to the offline mailing list.
    1. An initial reference tag is provided from the branch.
    2. All the tests from the test subdirectory run without problems.
    3. The reconstruction of real RAW data using the corresponding OCDB entries is working.
    4. The memory consumption is tested. In case of problems the authors of the code provide fixes.
    5. The CPU consumption of the simulation and reconstruction is tested. The authors of the code provide modifications in case of bad performance.
    6. The code is tested for memory leaks and run time problems using tools such as valgrind.
    7. Profiling charts are provided using tools as VTune, callgrind or Google performance tools.
    8. A simulation/reconstruction/reconstruction from raw data test with ~10000 pp min. bias event is run. The same test is run with 100 PbPb central events including event merging (the tests are run on lxbatch and GRID).
  3. The program librarian and the Git administrators introduce all the changes to the release branch.
  4. After successful testing period the program librarian provides a stable tag from the release branch.
  5. Additional changes and bug fixes can be introduced in the release branch. The program librarian provides new stable tag after the accumulation of sufficient number of changes or on demand.
  6. Releases on demand can de introduced, but the overall release time cannot be less than two weeks. The first week is needed to collect the new code, and the second for tests and fixes as explained above.
  7. Possibility to make one package for analysis and one for the rest of AliRoot with different release cycles will be provided. A more frequent release schedule for the analysis package requires shared libraries compatibility range. The analysis libraries include STEERBase, ESD, AOD, ANALYSIS, ANALYSISalice, JETAN, PWGs

 

History

The Geant3.21 based simulation program galice had been originally developed under the coordination of N.Van Eijndhoven for the Technical Proposal of the ALICE experiment at LHC. This code was based on the CERNLIB FORTRAN environment, using PAW N-tuple for the storage of the hits.

In 1998 the activities leading to the Technical Design Reports (TRDs) for the various sub-detectors of ALICE started. Simulation was an essential tool for the detailed design of the detectors. After a requirement collection phase within the collaboration, it became clear that a substantial upgrade of the galice package used for the Technical Proposal was necessary. In line with the policy of the collaboration and the recommendations of both the IT Division and the LHCC Computing Board (LCB), it was decided to develop a new environment based on Object Oriented techniques and implemented in C++.

Version 2 of galice was quickly prototyped, still using the Geant3.21 simulation program, but completely wrapped into a C++ class. The results of the simulation were objects stored in a Persistent Object Manager. At the time the code amounted to about 40 kLOC of Fortran code and 10 kLOC of C++. This rapid prototyping activity was possible thanks to the availability of the ROOT framework and to the active support of the ROOT team.

The results of this activity lead to a usable tool for simulation. At the same time both the advantages of the OO programming style and the soundness of the ROOT framework became clear. This lead to the official adoption of ROOT by the ALICE Off-line Project in November 1998. This also lead to the development of a completely C++ version of the simulation programme and to the development of the digitisation and reconstruction framework based on ROOT. Version 3 of the code, renamed AliRoot was completely rewritten in C++ and it was composed by 70 kLOC of C++ and 2 kLOC of FORTRAN.

 

OCDB folders

While the OCDB entries are expected not to change or to change without breaking backward compatibility, in the past it was not always the case; for this reason not all AliRoot versions can run with all OCDB base-folders. For Monte Carlo production we named the folders according to the following notation:
    /alice/simulation/2008/version/
where "version" is the name of the specific version starting from which the objects in the folder are supposed to work. When backward compatibility was broken, a new set of basefolders was added.

 

Inside the version folders there are three OCDB folders, named "Ideal", "Residual" and "Full":

  • The Ideal OCDB contains ideal calibration and alignment objects, corresponding to perfect knowledge of calibration parameters and of geometry.
  • The residual OCDB contains residual condition objects, simulating the best knowledge of calibration and alignment parameters after decalibration, survey and alignment procedures.
  • The full OCDB contains full condition objects, simulating the initial calibration and alignment parameters before any correction (before decalibration, survey and alignment procedures).