Status and new developments of the Generator Services

The Generator Services (GENSER) provide ready-to-use Monte Carlo generators, compiled on multiple platforms or ready to be compiled, for the LHC experiments. In this paper we discuss the recent developments in the build machinery, which allowed to fully automatize the installation process. The new system is based on and is integrated entirely with the "LCG external software" infrastructure, providing all the external packages needed by the LHC experiments.


Introduction
The Generator Services project [1] was started 10 years ago. Its purpose is to provide, mainly for the LHC community and experiments, the following components, necessary for the usage of Monte Carlo event generators: • Installed, ready to use MC generator libraries on network file systems (e.g. AFS and CVMFS) for a number of computing platforms.
• Binary tarfiles for the distribution to the remote sites, for a number of platforms.
• Source tarfiles for building the generators from scratch. While for many generators these are the same as on the author's distribution site, for some generators, such as Pythia 6 and Herwig, GENSER provides a build system and an examples subdirectory, also with a build system.  The list of supported computing platforms is decided in discussions with the representatives of the LHC experiments. Currently there are only Linux platforms in this list.
The active development of generators and auxiliary packages during the last 2 -3 years caused the change of conditions for the Generators Services. The generators implemented in C++, such as pythia8, sherpa, herwig++, reached the production quality. They are now requested by the experiments more than the fortran ones. The new generators, unlike the fortran ones, usually have one or several dependencies on the LCG (LHC Computing Grid) external software packages, such as FastJet [36] [37], python, Boost (see Figure 1). An upgrade of one of these packages to a newer version necessitates the rebuild of all dependent generators. For this reason the structure of GENSER repositories was changed. Now it follows the LCG external software releases, coming out on the average every one -two months. In order to automatize the rebuilding of GENSER packages according to this scheme, the GENSER build machinery was completely rewritten and integrated with the LCG external software infrastructure. The new system, called lcgcmake, is based on CMake [38] , in particular on its ExternalProject [39] module.

GENSER build and install procedure with lcgcmake
As mentioned above, one of the purposes of lcgcmake is to build a new GENSER tree following a new release of LCG external software. Apart from this, from time to time there are requests from LHC experiments or generator authors to install a new generator version or to add a completely new generator to GENSER. In order to trace such requests a wide usage of JIRA [40] is adopted.
The stages, involved in the typical GENSER service request life-cycle are the following:

• Receiving a new request
Typically the installation requests for new generators or new versions come from MC authors or the experiments. A JIRA ticket is immediately created.

• Implementation
The code driving all the necessary steps to build one particular generator is typically 10 -20 lines in the main steering file CMakeLists.txt (Appendix 1). Sometimes (a rare case) one  Figure 2). For every generator there is at least one integrity test: an executable is built and run. These are short tests, taking not more than a few minutes, only pass/fail status is checked. The integrity tests are run automatically after the generator build using CTest [43] • Signing off and installation If the results of the test builds and integrity tests described above are OK, the changes necessary to satisfy the request are approved for the release.

Some details of the implementation
The CMake ExternalProject module allows to define custom targets to drive download, update, patch, configure, build, install and test any external package. The code that defines these steps is a part of lcgcmake and is rather stable now. At the initialization lcgcmake generates Makefile, with which the actual build is performed. It was decided that the author's source tarfiles used to build packages should be taken from the GENSER intermediate repository, where they are put once and forever. This makes GENSER more self-contained, ensuring reproducibility of the build results.
The executables for the integrity tests mentioned above are built with CMake build systems. In these systems the CMake command find package is widely used. For the standard packages like Boost there are corresponding modules built in CMake. For other, less standard packages like HepMC, the corresponding modules are collected in the package cmaketools installed as a part of LCG external software. This package can be useful for any project with a CMake build system that use generators.

Conclusions
The Generator Services are widely used in production by the LHC experiments. However, an intensive development of GENSER continues in order to make it more reliable, convenient and flexible when used on a variety of commonly used computing platforms. The most recent major development is the migration to CMake described in this paper. It allowed to make the installation of the whole new GENSER tree corresponding to a new LCG external software release fully automatic and steerable from ElectricCommander, essentially reducing it to a single click of button. This development was performed, as usual, without interruption of the main services for the LHC experiments.