{'fraction_non_alphanumeric': 0.04060554355520866, 'fraction_numerical': 0.0135230799949175, 'mean_word_length': 4.589124480064928, 'pattern_counts': {'":': 0, '<': 27, '<?xml version=': 0, '>': 36, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Recola2: REcursive Computation of One-Loop Amplitudes 2

We present the Fortran95 program Recola2 for the perturbative computation of next-to-leading-order transition amplitudes in the Standard Model of particle physics and extended Higgs sectors. New theories are implemented via model files in the 't Hooft-Feynman gauge in the conventional formulation of quantum field theory and in the Background-Field method. The present version includes model files for the Two-Higgs-Doublet Model and the Higgs-Singlet Extension of the Standard Model. We support standard renormalization schemes for the Standard Model as well as many commonly used renormalization schemes in extended Higgs sectors. Within these models the computation of next-to-leading-order polarized amplitudes and squared amplitudes, optionally summed over spin and colour, is fully automated for any process. Recola2 allows the computation of colour- and spin-correlated leading-order squared amplitudes that are needed in the dipole subtraction formalism. Recola2 is publicly available for download at http://recola.hepforge.org.


Introduction
In the era after the Higgs-boson discovery the focus in elementary particle physics is on the precise validation of the Standard Model (SM) and the search for possible extensions thereof a.k.a. Beyond Standard Model (BSM) theories. Nowadays we are able to perform precision predictions in the SM for a vast number of observables as a result of the automation of one-loop QCD [1][2][3][4][5][6][7][8][9] and electroweak (EW) [1,[10][11][12][13][14] corrections. In the future, amplitude providers need to be able to calculate one-loop QCD and EW corrections in general weakly interacting theories. However, the automation of one-loop EW corrections for BSM theories is more involved as several intermediate steps are required. The first step consists in the definition of new models in terms of a Lagrangian and a subsequent determination of the Feynman rules. This can be done by means of Feynrules [15,16] and Sarah [17]. Then, the renormalization needs to be addressed which raises many questions for BSM theories as parameters cannot be necessarily linked to physical observables. Thus, many different renormalization schemes need to be investigated which in turn requires a systematic and flexible approach. Steps towards the automation of the renormalization for BSM theories have been undertaken in the FeynRules/FeynArts approach in Ref. [18]. Finally, the renormalized model file needs to be interfaced to a generic one-loop matrix-element generator. In Ref. [19] we proposed a complementary strategy to Ref. [18] combining the second and third step which requires a small set of external tools (FORM [20,21] and REPT1L [19]). Our approach makes use of treelevel Universal FeynRules Output (UFO) model files [22] and results in renormalized one-loop model files for Recola2, a generalized version of Recola, allowing anyone to compute any process in the underlying theory at the one-loop level, with the only restriction being available memory and CPU power. Much effort has been spent on the validation of our system, and for this purpose the alternative formulation of quantum field theory (QFT) in the Background-Field method (BFM) has been implemented. In this report we describe the Recola2 library and the Recola2 model files for the computation of tree and one-loop amplitudes in the SM, the Two-Higgs-Doublet Model (2HDM) and the Higgs-Singlet Extension of the SM (HSESM).
This article is organized as follows: In Section 2 we summarize the new features of Recola2 compared to the prior version Recola [14]. In Section 3 the installation instructions for the Recola2 library and the model files are given. In Section 4 we describe the usage of Recola2 and comment on all new subroutines related to models with extended Higgs sectors that can be called by the user. Finally, we conclude in Section 5 and list validation efforts in Appendix A.

New features in Recola2
Recola2 is an upgraded version of the Fortran95 code Recola [14] for the computation of tree-level and one-loop scattering amplitudes for general QFT, based on recursion relations [10]. At tree level the algorithm computes amplitudes using Dyson-Schwinger equations [23][24][25]. At one-loop order the recursion relies on the decomposition of one-loop amplitudes in terms of tensor integrals, computed by means of the Collier library [26], and tensor coefficients computed by Recola2, within the framework of dimensional regularization. The extension to BSM concerns, in particular, the computation of tensor coefficients as they are process-and theory-dependent. The Recola2 library can generate arbitrary processes in BSM theories and allows for the computation of tensor coefficients involving new structures compared to the usual formulation of the SM.
In Ref. [19] we have presented our algorithm for a fully automated renormalization and computation of one-loop amplitudes. The intermediate results of this approach are Recola2-specific renormalized model files which are derived from nothing but tree-level UFO format [22] by means of the tool REPT1L. For the 2HDM and HSESM we specify in Section 2.1.1 and Section 2.1.2 the modified Higgs potentials and Yukawa sector, respectively. The tree-level UFO model files have been derived using Feynrules [15,16]. With extended Higgs sectors the parameter space grows and requires renormalization of additional parameters. In Section 2.1.3 we list all implemented renormalization schemes available in the model files. In Section 2.2 we give details on the implementation of dimensional regularization and specify conventions used in MS renormalization schemes. In Section 2.3 we comment on the formulation of model files in the BFM and, finally, in Section 2.4 we list our conventions for the new fields used to define processes.

Extended Higgs sectors and their renormalization 2.1.1. Scalar potentials
Currently we support the 2HDM and HSESM as presented in Ref. [19] and summarized in the following. The models with extended Higgs sector are distinguished from the SM by modified scalar potentials and Yukawa couplings. We derived the models for CP-conserving Z 2 -symmetric renormalizable potentials. Under these constraints the most general scalar potential in the 2HDM reads [27] with Φ 1 , Φ 2 being Higgs doublets. The five couplings λ 1 . . . λ 5 and the two mass parameters m 2 1 and m 2 2 are chosen to be real. Further, we allow for softbreaking of the Z 2 symmetry which is parametrized by the real parameter m 2 12 . Before spontaneous symmetry breaking (SSB) the parameters are expressed in the symmetric, defining basis and by the EW gauge couplings g and g ′ in the gauge eigenbasis. Recola2 operates in the physical basis expressed by masses, mixing angles and electromagnetic coupling. For the 2HDM this results in the following identification of physical parameters: The masses are uniquely defined as the eigenvalues of the canonically normalized mass matrices. Here, M H l and M H h denote the light and heavy neutral Higgs-boson masses, respectively, M Ha denotes the pseudo-scalar Higgsboson mass and M H ± the charged Higgs-boson mass. Besides being positive definite the neutral ones are constraint to M H l < M H h . The angles α and β are introduced to identify mass eigenstates and Goldstone-boson degrees of freedom. We follow the conventions in Ref. [27] where the dependence on the angles is parametrized as which is a natural choice for studying aligned scenarios. Here, t β is defined as t β = vev 2 /vev 1 , i.e. the ratio of the vevs associated to Φ 2 and Φ 1 [19,28]. Below we give a selection of Feynman rules which can be used to fix the conventions. The angle α is defined in the window [−π/2, π/2], whereas the angle β is defined in the window [0, π/2]. This implies c α := cos α = 1 − sin 2 α, c β := cos β = 1 − sin 2 β and t β > 0. Finally, we define the soft-breaking scale M sb as We support two alternative sets of input parameters for mixing angles, namely: For the HSESM the most general CP-conserving Z 2 -symmetric renormalizable scalar potential reads with Φ being a Higgs doublet and S being a singlet field, and all parameters are real. We choose the following set of physical parameters: The angle α is defined in the same way as in the 2HDM and t β is defined as t β = vev s /vev, i.e. the ratio of the vevs associated to S and Φ [19]. Again, Recola2 operates in the physical basis expressed by masses, mixing angles and electromagnetic coupling. For comparison of phase conventions we list key couplings of type VVS (g µν omitted) and SSS in Table 1. The SM limit is reached for s αβ = −1 and s α = −1 in the 2HDM and HSESM, respectively.

Yukawa sector
While for the HSESM the fermionic sector is the same as in the SM, the 2HDM allows for a richer structure with both doublet fields Φ 1 and Φ 2 coupling to fermions. Imposing a diagonal CKM matrix and the Z 2 symmetry, which is essential for suppressing flavour-changing neutral currents at model vertex coupling tree level, leads to the natural flavour-conserving models. The full Yukawa Lagrangian with all possible types reads withΦ i being the charge conjugation of Φ i , and Γ d , Γ u , Γ l generically denote the up-type quark, down-type quark and lepton Yukawa couplings. The Q L , L L and d R , u R , l R denote the SM fermion doublet and singlet fields, respectively. The parameters h i,F trigger the desired Yukawa type as follows: In this convention, the Yukawa couplings are generically given by vertex coupling with h i,F representing either h i,d , h i,u or h i,l depending on the fermion type F . Note that the user can select the Yukawa type directly via set Z2 thdm yukawa type rcl (Section 4.1.4), without having to worry about the values of h i,F .

Renormalization schemes
The renormalization of the SM gauge couplings is performed as explained in Ref. [19]. We support the renormalization of α in the Thomson limit (α 0 ) or on the Z-pole (α Z ). Furthermore, α can be renormalized in the G F scheme, neglecting the muon mass in vertex and box contributions.
In the extended Higgs sectors the renormalization of mixing angles and new couplings needs to be addressed. We support various renormalization schemes inspired by Refs. [28][29][30][31][32][33][34][35][36]. For all model files, except for the SM ones, 1 the tadpoles are by default renormalized in the FJ Tadpole Scheme [28,35,38] which, roughly speaking, affects all parameters depending on the vev. In particular, all counterterms to physical parameters are gauge-parameter independent. Nevertheless we support other tadpole-counterterm schemes via appropriate shifts with respect to counterterms defined in the FJ Tadpole Scheme. Note that the distinction of different tadpole-counterterm schemes is only relevant for the MS renormalization of α, β and M sb , but not for onshell schemes or the MS renormalization of parameters of the defining basis, i.e. λ i , µ i , because then the tadpoles necessarily drop out. 2 In summary, we distinguish between the following tadpole-counterterm schemes present in the literature:

MDTS:
In the Mass-Diagonal Tadpole counterterm Scheme no tadpole counterterms emerge for two-point functions of physical fields. See the Feynman rules in Ref. [37].

MTS:
In the Minimal Tadpole counterterm Scheme the translation to the physical basis is done in such a way that the tadpole counterterms only appear in the quadratic terms of the Higgs potential. See Eq. (6) in Ref. [39].
The masses and fields of new (scalar) fields are renormalized in the onshell scheme in the same way as in the SM. The only remaining parameters requiring renormalization are mixing angles and the soft-breaking scale M sb in the 2HDM. Since α, β and M sb are considered as independent parameters (or are related to direct derivatives thereof, e.g. c αβ , t β , s α , . . .) we formulate all renormalization schemes directly for the corresponding counterterms δα, δβ (δt β ) and δM 2 sb .
• MS schemes [28,32,33,36]: We support standard MS schemes. In each of these schemes terms proportional to ∆ UV are subtracted as explained in Section 2.2. The UV finiteness of matrix elements can be tested by varying the scale µ UV . The actual scale dependence of the scheme can be probed by varying the scale µ MS . The counterterms can be derived from suited vertices of the theory, or from the pole part of the off-diagonal field renormalization constants.
δα MS : In our conventions for the 2HDM and HSESM (see also Ref. [19]) we get for α in the FJTS: which can be translated to other tadpole schemes as follows with t H h H l and t H h H l ,MTS being the tadpole counterterms to the neutral mixing energy in the FJTS and MTS tadpole counterterm schemes, respectively.
δλ MS 3 , δλ MS 345 : Instead of α being renormalized MS, the user can choose between λ 3 and λ 345 . In the 2HDM this is equivalent to define the counterterm of α in the following ways: 3 while the results in the other tadpole counterterm schemes read The MS scheme (13) corresponds to the popular DR (MS) scheme in the Minimal Supersymmetric SM (see e.g. Ref. [32]). Note that the finite parts of the tadpoles are, in general, gauge dependent, and we fix them in the 't Hooft-Feynman gauge. The MS/MDTS scheme is used by default for δβ.
δt MS β : In the HSESM we renormalize t β in the MS scheme using the vertex V H h H l H l and require the pole part (P.P.) to vanish: For t β we offer the possibility to switch to the MDTS scheme which is related to the FJTS via We do not support the MTS for t β in the HSESM. The finite parts of the tadpoles are, in general, gauge dependent, and we fix them in the 't Hooft-Feynman gauge. The MS/MDTS scheme is used by default for δt β in the HSESM.
This scheme is the default. Alternatively, m 2 12 can be renormalized MS which is equivalent to define • p * schemes [19,30,31,34,35]: The p * scheme is derived via the diagonalization of the effective mass matrix requiring vanishing scale dependence [30,31]. In the 2HDM, this scheme can be used also for the renormalization of the mixing angle β yielding the following solutions: δα p * : δβ p * 1 : δβ p * 2 : Here, Σ H h H l , Σ HaG 0 and Σ H ± G ± denote the neutral, pseudo-scalar, and charged scalar mixing-energy, respectively, and t H l H h , t HaG 0 , t H ± G ± are the corresponding tadpole counterterms. The schemes are formulated via the BFM in the 't Hooft-Feynman gauge, i.e. for the quantum gauge parameter ξ Q = 1 [40]. The scheme δα p * is valid in the 2HDM and HSESM, whereas the schemes δβ p * 1 and δβ p * 2 can only be used in the 2HDM.
• on-shell schemes [19,29,35]: In these schemes, the counterterms for the mixing angles are defined via on-shell mixing field-renormalization constants in the ξ Q = 1 gauge in the BFM. We express the counterterms in terms of mixing energies as follows δα OS : δβ OS 1 : δβ OS 2 : The scheme δα OS is valid in the 2HDM and HSESM, whereas the schemes δβ OS 1 and δβ OS 2 can only be used in the 2HDM.

MS renormalization and scale dependence
Recola2 distinguishes between poles in ǫ of infrared (IR) and ultraviolet (UV) origin by introducing the parameters µ UV , ǫ UV and µ IR , ǫ IR in all tensor integrals and counterterms, together with Following the conventions of Collier [26,41] and Ref. [42], the parameters ∆ UV , ∆ IR and ∆ IR2 that contain the poles in ǫ absorb a normalization factor of the form 1 + O(ǫ). In terms of these parameters, the one-loop amplitude A 1 takes the general form The term A UV 1 vanishes after (UV) renormalization. The a priori unphysical scale µ UV should either cancel between the tensor integrals and the counterterms, or it should receive a physical interpretation as for example when it is identified with the renormalization scale µ MS in the MS scheme 4 for the strong coupling constant g s . In Recola2, the MS renormalization scale µ MS is introduced as a new independent scale by a modified MS renormalization where instead of ∆ UV the term is subtracted in MS schemes. As a consequence, the renormalized one-loop amplitude becomes which is independent of µ UV but can depend on µ MS when parameters are renormalized MS. Note that in the extended Higgs sectors besides the strong coupling constant g s additional sources of scale dependence emerge. The numerical evaluation of the renormalized amplitude involves parts which depend on ∆ UV and µ UV at intermediate steps. The independence of A 1 on ∆ UV and µ UV can be verified numerically by varying these parameters.

Soft and collinear singularities
In Recola2 collinear singularities are regularized as in Recola according to the input fermion masses which are forwarded to Collier, while soft singularities are always regularized dimensionally. 5 In the case of massless fermions dimensional regularization is used, and the scale dependence of regularized integrals is parametrized by the IR scale µ IR . If, on the other hand, the fermion has been assigned a regulator mass, its collinear singularities are regularized by this mass parameter. In this case, the parameter µ IR can be interpreted as a photon-mass regulator.

Background-Field Method
Recola2 supports the Background-Field Method (BFM) as a complementary method to the usual formulation of QFT. The implementation is realised for each individual model as a separate model file. Whether a model file is formulated in the BFM is printed in the Gauge entry in the initialisation of the model. For example, the SM BFM initialisation reads: 't Hooft-Feynman BFM Model generation: Tue Aug 29 18:58:55 2017 The BFM and the usual formulation of QFT are treated on equal footing, and, from the user perspective, models formulated in the BFM can be used as any other model since the same conventions for background fields in the BFM and the usual fields (Section 2.4) were chosen. The BFM comes with additional fields, so-called quantum fields, which cannot be selected as external states of matrix elements because they only appear inside loops. When drawing the currents to one-loop scattering processes the quantum fields can be seen at intermediate steps. For instance, the propagation of a gluon quantum field g Q along the loop line (the line distinguished by the cross at the beginning and end) is visualized in Fig. 1. Note that for all model files formulated in the BFM the fermion fields take the role of both, quantum and background field and no explicit distinction is made [19].
All renormalization schemes available in the usual formulation are also available in the BFM allowing for powerful cross checks. There are, however, (higher-order) differences for mass counterterms due to the expansion performed within the complex-mass scheme (see Ref. [19]). For a precise numerical comparison of both methods it is recommended to set the widths of all particles to zero where these differences disappear. In practical calculations the BFM formulation is 10−15% faster than the conventional formulation which is due to the need of less current structures. On the other hand, the generation of processes takes ∼ 50% longer in the BFM. Figure 1: Visualization of a branch with a quantum field.

Conventions
Recola2 uses the same conventions for particle identifiers (of type character) as Recola [14] with the exception of the Goldstone bosons: Other SM fields as well as conventions for polarizations and the normalization of the cross section are given in Ref. [14].

Installation
Recola2 uses the Collier library and Recola2-specific model files. In order to facilitate building Recola2 we provide the following two options: • Recola2-Collier package (Section 3.1): The configuration and compilation of Recola2, Collier, and a model file is performed at once, using a CMake script which resolves all dependencies automatically.
• Recola2-stand-alone package (Section 3.2): A stand-alone version which requires the user to resolve the dependence to Collier and model files by hand.
The Recola2 library and model files are available from the web site http://recola.hepforge.org. The compilation requires the CMake build system.

The Recola2-Collier package
The package recola2-collier-X.Y.Z contains the version X.Y.Z of the Recola2 library together with all model files. After downloading the file recola2-collier-X.Y.Z.tar.gz, extract the tarball in the current working directory with the shell command: This operation creates the directory recola2-collier-X.Y.Z containing the following files and folders: • CMakeLists.txt, build: CMake configuration for the compilation of the Recola2, Collier and model-file libraries in the proper order. The build directory, where CMake puts all necessary files for the creation of the library; • recola2-X.Y.Z: main directory of the Recola2 package recola2-X.Y.Z (see Section 3.2 for details); • model-files-X.Y.Z: directory containing the Recola2 model files: Each model carries the same version as the Recola2 library; • project cmake: a test configuration which demonstrates how to link Recola2 to an external project using CMake; this is discussed in Section 3.

The Recola2 demo files
The Recola2 demo files are located in recola2-X.Y.Z/demos. In order to compile and run executables for the demo programs the command ./run <demofile> can be executed with <demofile> being either demo0 rcl, demo1 rcl, demo2 rcl, demo3 rcl, demo4 rcl, or demo5 rcl. Alternatively, the user can execute make <demofile> in the build directory recola2-X.Y.Z/build to compile the respective executable.
The demo programs exemplify the usage of Recola2 for various purposes: • demo0 rcl: Basic usage of Recola2.
• demo1 rcl: Usage of Recola2 for more than one process simultaneously, with explicit modification of input parameters and with selection of specific  helicities for the external particles and of certain powers of the strong coupling constant. In addition, files with L A T E X source code for diagrams are generated.
• demo2 rcl: Usage of Recola2 for the selection of resonant contributions and pole approximation.
• demo3 rcl: Usage of Recola2 for the computation of colour-and/or spincorrelation.
• demo4 rcl: Usage of Recola2 for the computation of decay widths using the ex-ample of light and heavy neutral Higgs decays into Higgs and gauge bosons: Moreover, the use of different renormalization schemes in the extended Higgs sector is demonstrated.
• demo5 rcl: Usage of Recola2 for the selection of powers of coupling types in the new system at the example of a vector-boson-fusion partonic channel.
Note that the demo files demo0 rcl, demo1 rcl, demo2 rcl, demo3 rcl are identical to the ones in Recola, but can be used with any current Recola2 model file.
For each <demofile> corresponding C ++ (cdemo) and Python (pydemo) demo files are available. The C ++ demo files are compiled in the same way, substituting <demofile> by the precise cdemo file name. The C ++ interface is described in Section 4.5. The Python demo file can be run directly without compilation. See Section 4.6 for more details on the Python interface.
The demos directory also contains the shell script draw-tex which compiles all L A T E X files of the form process *.tex present in the folder and creates the corresponding .pdf files. It can be run by invoking ./draw-tex in the demos directory. Recola2 provides the same functionally for drawing currents as Recola and we refer to Ref. [14] for details.

A minimal executable with CMake
The purpose of this section is to demonstrate how to link Recola2 to a custom program using the CMake build system. The Recola2-Collier package comes with a Fortran95 and C ++ test program in the directory project cmake. We discuss the Fortran95 version, program.f90, which merely contains the lines of code: program main use recola end program That is, the program includes Recola2 and can be extended by the user at will. For the compilation the essential part is the CMake configure file CMakeLists.txt. A template CMakeLists.txt is provided: The first two lines define a new project and declare Fortran as the main language. 7 The third statement adds a new executable named program which is compiled from the source program.f90. Since the program uses Recola2 it needs to be linked against it. This is achieved in two steps. In the first step, the Recola2 package is searched for via the CMake command find package. The version requirement exact can be relaxed by removing it and omitting the minor/patch version. On success, this command fills the CMake variables • RECOLA LIBRARY DIR: directory containing the Recola2 library; • RECOLA INCLUDE DIR: directory containing the Recola2 header files, i.e. the Fortran modules *.mod, the C header file recola.h, and the C ++ header file recola.hpp; • RECOLA LIBRARY PATH: the absolute path to the Recola2 library file librecola.so (or librecola.a, librecola.dynlib).
On failure, the configuration stops printing an error. After successfully finding the Recola2 package the executable is linked with the Recola2 library. Note this script works independent of whether Recola2 is compiled as shared or static library, whether the underlying program is Fortran, C or C ++ based, and independent of the underlying operating system or compilers. For further tuning we refer to https://cmake.org/Wiki/CMake.

The Recola2 stand-alone package
In this section we discuss the compilation of the stand-alone Recola2 library, the compilation of the model files, and all available compiler options. We assume the user has acquired a local copy of Collier 8 and that he/she followed the Collier compilation instructions.
The archives

The Recola2 model-file compilation
In the current version of Recola2 the model files are a dependency at compile time, 9 thus, the desired model needs to be compiled first. To this end, extract one of the model-file tarballs with the shell command: This operation creates the directory modelfile-X.Y.Z containing the following files and folders: • CMakeLists.txt, config, build: CMake configure files required for the generation of the Recola2 model file Makefile. The build directory is where CMake puts all necessary files for the creation of the library; • src: model-file source directory; • include: all Fortran module files *.mod are placed inside this folder.
The compilation of the model file proceeds by changing to the build directory 10 and executing there the shell command "cmake [options] .." (creating a Makefile in modelfile-X.Y.Z/build), followed by make:

make [options]
Note that .. is the relative path pointing from the build directory one level higher to where the top-level CMakeLists.txt of the model file is located. By default, the configuration will search for the Collier library in directories next to the model-file directory. It is possible to force the use of a particular Collier version by providing a path. The CMake variable collier path can be used to pass the (absolute/relative) path to the directory containing the Collier library:

-Dcollier_path=<PATH_TO_COLLIER>
By using this option it is assumed that the Collier module files are located inside the path:

<PATH_TO_COLLIER>/modules
As a third alternative the environment variables COLLIER INCLUDE DIR and COLLIER LIBRARY DIR can be set to the directories including the Collier modules and Collier library, respectively. In this case the complete sequence of calls reads: cd modelfile-X.Y.Z/build export COLLIER_LIBRARY_DIR=<PATH_TO_COLLIER_LIBRARY> export COLLIER_INCLUDE_DIR=<PATH_TO_COLLIER_MODULES> cmake [options] ..

make [options]
We stress that the library paths should not point to the precise Collier library file, but only to the directory containing the library.
If no other options are specified, CMake automatically searches for installed Fortran compilers and chooses a suited one. The user can force CMake to use a specific compiler by appending to the cmake command the option -DCMAKE_Fortran_COMPILER=<comp> where <comp> can be gfortran, ifort, pgf95, ... or the full path to a compiler.
By default, the installation sequence generates the model file as a shared library libmodelfile.so(/.dynlib) in the directory modelfile-X.Y.Z, with the corresponding module files placed in the include subdirectory. The option -Dstatic=ON causes CMake to create the static library instead of the shared one.
After the configuration the compilation can be run parallelised which is recommended as the model files contain plenty of independent source files. Parallelised compilation is performed via

make -j <THREADS>
where <THREADS> is the number of parallel compilation units. The CMake Makefile allows the compilation command to be run in verbose mode via:

make VERBOSE=True
If desired, the model file can be installed into the system via the command:

make install
A default install prefix is set automatically by CMake, 11 but can be altered by configuring the Makefile via -DCMAKE_INSTALL_PREFIX=<INSTALLATION_PATH> with <INSTALLATION PATH> being a custom installation path, e.g. $HOME.

The Recola2 library compilation
The configuration and compilation of Recola2 proceeds in the very same way as for model files, with the exception that, in addition, a specific modelfile path has to be set.
In the first step, extract the Recola2 tarball with the shell command: tar -zxvf recola2-X.Y.Z.tar.gz This operation creates the directory recola2-X.Y.Z containing the following files and folders: • CMakeLists.txt, config, build: CMake configure files required for the generation of the Recola2 Makefile. The build directory is where CMake puts all necessary files for the creation of the library; • src: Recola2 source directory; • demos: directory with demo programs illustrating the use of Recola2, including shell scripts for their compilation and execution; • include: directory with C and C ++ header files; all Fortran module files *.mod are placed inside this folder; The standard sequence for the compilation reads where <PATH TO MODELFILE> and <PATH TO COLLIER> is the path to the directory containing the compiled model-file and Collier library, respectively. By using this option for Collier it is assumed that the Collier module files are located inside the path:

<PATH_TO_COLLIER>/modules
Alternatively, the environment variable MODELFILE PATH can be set to the directory including the model file CMake configure files 12 or the model-file library. In this case the sequence of calls reads: We support the same [options] for configuration and compilation of Recola2 as for the model files. Note also that the paths to the Collier library and module files can be set via environment variables as described in Section 3.2.1.
Starting with Recola2 we support a Python interface. By default, the CMake configuration will search for the Python 2.7 library, header and executable and will, on success, build the library pyrecola (see Section 4.6). We support Python 3.x which can be enabled in the configuration via -Dwith_python3=On and, evidently, requires the Python 3.x library, header and executable to be present in the system. We note that the Recola2 build is not affected if the Python dependencies are not fulfilled.
Finally, Recola2 is equipped with a few test routines allowing to check the proper integration of Recola2 into the system. In order to be able to compile the tests the configuration needs to be run with:

-Dwith_smtests=On
Then, after building Recola2, the tests can be run via make test or by invoking ctest in the directory recola2-X.Y.Z/build. Note that the tests should only be run with a SM model file, otherwise the tests will fail.

Usage of Recola2 in extended Higgs sectors
In order to use Recola2 in a Fortran program its modules have to be loaded by including the line use recola in the preamble of the respective code, and the library librecola.so, librecola.dynlib or librecola.a has to be supplied to the linker. This gives access to the public functions and subroutines of the Recola2 library described in the following subsections. The names of all these routines end with the suffix " rcl". This name convention is supposed to avoid conflicts with routine names present in the master program and increases readability by allowing for an easy identification of command lines referring to the Recola2 library.
Typically, an application of Recola2 involves the following five steps: • Step 1: Setting input parameters (optional) The input needed for the computation of processes can be set by calling dedicated subroutines as provided by Recola2. See Section 4.2 for the additional set of methods related to extended Higgs sectors. Since Recola2 provides default values for all input parameters, this first step is optional.
• Step 2: Defining the processes Before Recola2 can be employed to calculate matrix elements for one or more processes, each process must be declared and labelled with a unique identifier. This is done by calling the subroutine define process rcl for every process, as described in Ref. [14]. The functionality of the process definition has been extended which is documented in Section 4.3 for subroutines that are concerned.

• Step 3: Generating the processes
In the next step the subroutine generate processes rcl is called which triggers the initialisation of the complete list of processes defined in step 2. As a result, all relevant building blocks for the recursive computation of off-shell currents are generated (see Ref. [14] for details).

• Step 4: Computing the processes
The computation of the amplitude and of the squared amplitude is performed by means of the subroutine compute process rcl, which uses the process-dependent information on the recursive procedure derived in step 3. The subroutine compute process rcl is called with the momenta of the external particles provided by the user. In a Monte Carlo integration, the call of compute process rcl is repeated many times for different phase-space points.
Detailed information on the subroutines that can be employed in step 4 can be found in Ref. [14]. The functionality of the process computation has been extended which is documented in Section 4.4 for subroutines that are concerned.

• Step 5: resetting Recola2
Finally, by calling the subroutine reset recola rcl, the processdependent information generated in steps 2-4 is deleted and the corresponding memory is deallocated. The input variables keep their values defined in step 1 before.
Note that these steps have to be followed in the order given above. In particular, after step 3 no new process can be defined unless Recola2 is reset (step 5). After step 5 the user can restart with step 1 or step 2. More information on the allowed sequence of calls can be found in Ref. [14]. Examples are found in the directory demos and are described in Section 3.1.1.

Input subroutines for parameters of extended Higgs sectors
The following input subroutines are complementary subroutines to the original ones in Recola and can be used to set input parameters and renormalization schemes in extended Higgs sectors. Note that these subroutines can only be called if supported by the selected model file, otherwise Recola2 prints an error message and stops.

set pole mass hl hh rcl (ml,gl,mh,gh)
This subroutine sets the pole masses and widths (in GeV) of the light (H l ) and heavy (H h ) Higgs bosons to ml, gl and mh, gh, respectively (ml, gl, mh and gh are of type real(dp)). The pole masses must fulfil the condition ml< mh. Note that the degenerate mass scenario is not supported.

set pole mass ha rcl (m,g)
This subroutine sets the pole mass and width (in GeV) of the pseudo scalar Higgs boson (H a ) to m and g, respectively (m and g are of type real(dp)).

set pole mass hc rcl (m,g)
This subroutine sets the pole mass and width (in GeV) of the charged Higgs boson (H ± ) to m and g, respectively (m and g are of type real(dp)).

set tb cab rcl (tb,cab)
This subroutine sets the value of t β to tb, and c αβ to cab [tb and cab are of type real(dp)]. The value of tb is strictly greater than zero and the value of cab must fulfil −1 ≤ cab ≤ 1.
If these conditions are violated an error is raised. The renormalization for c αβ and t β is fixed via the renormalization of α and β which can be set using the subroutines use mixing alpha rs scheme rcl (Section 4.1.6) and use mixing beta rs scheme rcl (Section 4.1.7), respectively. See Section 2.1.3 for more details.

set msb rcl (msb)
This subroutine sets the value of the soft-Z 2 -breaking scale M sb to msb (msb is of type real(dp)). The renormalization scheme for M sb is set with use msb rs scheme rcl (Section 4.1.9). See Section 2.1.1 for more details. Model support: 2HDM

set sa rcl (sa)
This subroutine sets the value of s α to sa [sa is of type real(dp)]. The input value of sa must fulfil −1 ≤ sa ≤ 1, otherwise an error is raised. The renormalization scheme for s α is fixed via the renormalization of α which can be set with use mixing alpha rs scheme rcl (Section 4.1.6). See Section 2.1.1 for more details.

set tb rcl (tb)
This subroutine sets the value of t β to tb [tb is of type real(dp)]. The passed value of tb must fulfil tb > 0, otherwise an error is raised. The renormalization scheme for t β is set with use tb rs scheme rcl (Section 4.1.12). See Section 2.1.1 for more details.

use tb msbar scheme rcl (s)
This subroutine sets the renormalization scheme for t β to s (of type character). The following schemes are supported: s renormalization-scheme description 'FJTS' t β is renormalized MS, FJ tadpole scheme (14) 'MDTS' t β is renormalized MS, MD tadpole scheme (15) Note that only one of the schemes can be used at a time. The input value of t β is set with set tb rcl (4.1.11). See Section 2.1.3 for more details.

Compatibility with Recola input subroutines
In this section we list new subroutines, original ones with modified behaviour, and no longer supported ones that are kept for backward compatibility. We stress that all subroutines existing in Recola can be called in Recola2.

use gfermi scheme rcl (g,a)
△ ! This subroutine (see Section 4.2.18 in Ref. [14]) has a different behaviour when being used in combination with the optional argument g which represents the Fermi constant G F . Internally, g is translated to α according to with the currently active values for the (real) vector-boson masses M W , M Z . Therefore, the vector-boson masses should be set before calling this subroutine.

set parameter rcl(param,value)
This subroutine sets the value of param (of type character) to value (of type complex(dp)). Note that only independent couplings, masses and widths can be set via this subroutine, without any consistency checks being performed. An imaginary part of value can lead to undefined behaviour, and value should be real even though it is of type complex(dp). The allowed values for param depend on the model file and can be looked up in the subroutine set parameter mdl defined in class particles.f90 of the respective model file. For example, setting the light Higgs-boson mass M H l to 125 GeV in the 2HDM or HSESM is achieved as follows: call set_parameter_rcl("MHL", complex(125d0, 0d0)) For extended Higgs sectors the dedicated subroutines in Section 4.1 should be used to set input parameters. When calling set parameter mdl with arguments that are incompatible with the selected model file, a warning is printed. The program does not stop, and the call has no effect.

set renoscheme rcl(ctparam,renoscheme)
This subroutine sets the renormalization scheme for the parameter with name param (of type character) to renoscheme (of type character).
The allowed values for ctparam and renoscheme depend on the model file and can be looked up in the subroutine set renoscheme mdl defined in fill ctparameters.f90 of the respective model file. For example, setting the renormalization scheme of the mixing angle α to the p * scheme (18) in the 2HDM or HSESM is achieved as follows: call set_renoscheme_rcl("da_QED2", "ps_bfm") For extended Higgs sectors the dedicated subroutines in Section 4.1 should be used to set renormalization schemes. When calling set renoscheme mdl with arguments that are incompatible with the selected model file, a warning is printed. The program does not stop, and the call has no effect.

4.2.5.
set complex mass scheme rcl, set on shell scheme rcl △ ! These subroutines are deprecated and calling any of them has no effect. Note that the model files are all derived in the complex-mass scheme.

set dynamic settings rcl (n)
△ ! This subroutine is not supported yet and calling it has no effect.

set print level parameters rcl (n)
This subroutine, which can be called before the process generation but also during the process computation, sets internal variables governing the output of input, derived and counterterms parameters: • n = 0: No parameters are printed.
• n = 2: Input and derived parameters are printed.
By default, only input parameters are printed.

set print level RAM rcl (n)
△ ! This subroutine is not supported yet and calling it has no effect.

set collier output dir rcl (dir)
This subroutine, which can be called before the process generation, sets the Collier output directory to dir (dir is of type character), with dir being a relative or absolute path. The default Collier output directory can be enforced by passing dir = 'default'.

Updates on process definition
In this section we describe the new treatment of powers of types of fundamental couplings in Recola2. In theories with a SM gauge group structure amplitudes are proportional to g ns s e n−ns , where g s and e represent the strong and electroweak gauge couplings. For a given process and power n s in g s the power n is unambiguously determined. For this special case of theories we support the original Recola methods select gs power * where only the powers in g s are selected, 13 but for more general theories the user has to employ the new general selection methods given in Sections 4.3.1 and 4.3.2, exclusively available in Recola2.
The treatment of different coupling types is kept general and uses the information on coupling powers as defined by model files in the UFO format. For all model files we choose the powers in the strong and EW gauge couplings as follows: coupling type position coupling constant The position is relevant only when calling a subroutine which requires the couplings powers as an array of integers, e.g. the subroutines in Section 4.4.
For the selection of powers a string identifier is used as described in the following.
4.3.1. select power BornAmpl rcl (npr,cid,power), unselect power BornAmpl rcl (npr,cid,power) This pair of subroutines allows to select/unselect the contribution to the Born amplitude proportional to general powers in coupling types c n id of the underlying theory. Here, c id is set to cid (of type character), n is given by the integer argument power, and npr is the process identifier (of type integer). The variable cid accepts the following values: 'QCD': power in g s , 'QED': power in e.
All other contributions to the Born amplitude keep their status (selected or unselected), according to previous calls of selection subroutines. The selection of the contributions to the loop amplitude remains unaffected as well. New values for cid will be introduced in the future for theories with additional types of couplings (as appear, for instance, in theories with new gauge couplings or in effective field theories). For SM-like theories with the only two fundamental coupling types 'QCD' and 'QED' the methods select gs power BornAmpl rcl and unselect gs power BornAmpl rcl (see Ref. [14]) can be used instead.

4.3.2.
select power LoopAmpl rcl (npr,cid,power), unselect power LoopAmpl rcl (npr,cid,power) This pair of subroutines allows to select/unselect the contribution to the loop amplitude proportional to general powers in coupling types c n id of the underlying theory. Here, c id is set to cid (of type character), n is given by the integer argument power, and npr is the process identifier (of type integer). The variable cid accepts the following values: 'QCD': power in g s , 'QED': power in e. All other contributions to the loop amplitude keep their status (selected or unselected), according to previous calls of selection subroutines. The selection of contributions to the Born amplitude remains unaffected as well. New values for cid will be introduced in the future for theories with additional (gauge) couplings or in effective field theory. For SM-like theories with the only two fundamental coupling types 'QCD' and 'QED' the methods select gs power LoopAmpl rcl and unselect gs power LoopAmpl rcl (see Ref. [14]) can be used instead. This gives access to the Recola namespace. The functions are called in the typical C ++ syntax, e.g.: Recola::define_process_rcl(1, "u u -> u u", "NLO"); The namespace identifier "Recola::" can be omitted by importing Recola as follows: #include "recola.hpp" using namespace Recola The Fortran95 subroutines translate to functions in C ++ with the argument types being identified according to:

Fortran95
C ++ integer int integer, dimension(:) int[ ] logical bool real(dp) double real(dp), dimension(:) double[ ] complex(dp) std::complex double character(len=*) std::string For multi-dimensional arrays, such as the momenta p, the conventions for the order of the indices is the same as in Fortran95, and any necessary transposition is performed within the interface. The complex numbers are the only additional C ++ Standard Library dependency used in the interface. Return values are handled by call-by-reference, thus, all C ++ functions are declared as void functions. Optional arguments are implemented via function overloading, i.e. missing arguments are replaced by default values. For instance, the call Recola::use_alphaZ_scheme_rcl (); enables the use of the α(M Z ) scheme (see Section 4.2.2 in Ref. [14]), using the default value for α(M Z ) which is hard-coded in Recola. Providing an explicit argument via Recola::use_alphaZ_scheme_rcl (0.0078125); allows to use a different value for α(M Z ) than the default in the running session.
The original Fortran95 demo files are available as C ++ demo files. The compilation of the C ++ demo files follows the same steps as given in Section 3.1.1, i.e. by either running make <demofile> in the build folder or directly via the run script ./run <demofile> in the demo folder, with <demofile> taking the values cdemo0 rcl, cdemo1 rcl, cdemo2 rcl, cdemo3 rcl, cdemo4 rcl, or cdemo5 rcl. The content of each cdemo file is identical to the content of the corresponding (Fortran95) demo file.
A few C ++ functions differ from the usage and naming convention of the Fortran95 subroutines owing to the conceptual difference of optional arguments and arrays in Fortran95 and C ++ . Thus, the functions • use gfermi scheme rcl (Section 4.2.18 in Ref. [14]), • set gs power rcl (Section 4.3.2 in Ref. [14]), are replaced by the following ones:

use gfermi scheme rcl
This C ++ function takes no arguments and calls the subroutine use gfermi scheme rcl(g,a) (Fortran95) neither setting a value for g nor a. This corresponds to selecting the G F scheme as renormalization scheme for the EW coupling and using the default value for the Fermi constant G F which is hard-coded in Recola.

use gfermi scheme and set gfermi rcl(g)
This C ++ function calls the subroutine use gfermi scheme rcl(g,a) (Fortran95), passing the value g of type double.

use gfermi scheme and set alpha rcl(a)
This C ++ function calls the subroutine use gfermi scheme rcl(g,a) (Fortran95), passing the value a of type double.

set gs power rcl(npr,gsarray,gslen)
This C ++ function calls the subroutine set gs power rcl(npr, gsarray) (Fortran95), passing the value of npr (of type int) and gsarray (of type int[] [2]). The value gslen is the length of the first index of gsarray which needs to be passed explicitly to Fortran95.

Missing subroutines
The subroutines get colour configurations rcl (Section 4.5.5 in Ref. [14]) and get helicity configurations rcl (Section 4.5.6 in Ref. [14]) are currently not included in the C ++ interface. The authors are willing to provide a custom solution, upon request, to include their functionality.

Python interface
The Recola2 package includes a Python interface with the same naming conventions for the subroutines as given in Sections 4.2-4.6 in Ref. [14] and the new subroutines in Sections 4.1, 4.2, and 4.3. The Python interface requires to build an additional library, called pyrecola, which is done automatically alongside the Recola2 library if the Python libraries are found on the system and if Recola2 is build as a shared library. See Section 3.1.1 for more details on building pyrecola. The basic usage is identical to the one in Fortran95 and follows the computation flow presented at the beginning of Section 4. In order to use Recola2 in a Python program the Recola2 library needs to be loaded as follows: import pyrecola This step requires the python library pyrecola.so to be present in the current working directory, or, alternatively, by updating the environment path PYTHONPATH as follows export PYTHONPATH=$PYTHONPATH:<PATH_TO_PYRECOLA> where <PATH TO PYRECOLA> is the absolute path to the directory containing pyrecola.so. Once the Recola2 namespace is accessible the functions are called in the typical Python syntax, e.g.: pyrecola.define_process_rcl(1, 'u u -> u u', 'NLO') The namespace identifier "pyrecola." can be omitted by importing Recola2 as follows: from pyrecola import * Instead of loading all methods via * specific ones can be imported, e.g.
from pyrecola import (define_process_rcl, generate_process_rcl, compute_process_rcl) The Fortran95 subroutines translate to functions in Python with the argument types being identified according to: Fortran95 Python integer int integer, dimension(:) list logical bool real(dp) float real(dp), dimension(:) list complex(dp) complex character(len=*) str For multi-dimensional arrays, such as the momenta p, the conventions for the order of the indices is the same as in Fortran95, and any necessary transposition is performed within the interface. Note that explicit type checking is performed in the Python/C API interface (pyrecola.c).
In contrast to the Fortran95 and C ++ interface, computed results are returned by function calls. For example, the call als = get_alphas_rcl() returns the value of α s and stores it in the variable als. In general, the return value is a tuple of variables. The return type of a function can be inquired from the documentation as described below or inferred from the Python/C API interface pyrecola.c.
Furthermore, optional arguments are not implemented by operator overloading, but via keyword arguments which allow most of the Python methods to be called in the same way as done in Fortran95 with a few exceptions discussed below. For instance, the call pyrecola.use_alphaZ_scheme_rcl() enables the use of the α(M Z ) scheme, using the default value for α(M Z ) which is hard-coded in Recola2. Providing an explicit argument as pyrecola.use_alphaZ_scheme_rcl (a=0.0078125) allows to use a different value for α(M Z ) than the default in the running session.
The Python interface comes with a built-in documentation for every public method in Recola2 and can be accessed by calling help inside Python on either the module pyrecola itself, or on specific methods. For instance, calling help(use alphaZ scheme rcl) returns >>> import pyrecola >>> help(pyrecola.use_alphaZ_scheme_rcl) Help on built-in function use_alphaZ_scheme_rcl in module pyrecola: use_alphaZ_scheme_rcl(...) use_alphaZ_scheme_rcl(a=None) Sets the EW renormalization scheme to the alphaZ scheme. a -> Sets value of alpha to 'a' For 'a=None' (DEFAULT) the hard-coded value for alpha is used.
The original Fortran95 demo files are available as Python demo files. No compilation of the demo files is required and they can be run directly by executing python <demofile> in the demo folder, with <demofile> taking the values pydemo0 rcl.py, pydemo1 rcl.py, pydemo2 rcl.py, pydemo3 rcl.py, pydemo4 rcl.py or pydemo5 rcl.py. The content of each pydemo file is identical to the content of the corresponding (Fortran95) demo file.
A few Python functions differ from the usage of the Fortran95 subroutines owing to the conceptual difference of optional arguments in Fortran95 and Python. The following functions are concerned • get amplitude rcl (npr,order,colour,hel,pow=None,gs=None) • get squared amplitude rcl (npr,order,pow=None,als=None) • get polarized squared amplitude rcl (npr,order,hel,pow=None,als=None) • get colour correlation rcl (npr,i1,i2,pow=None,als=None) • get spin correlation rcl (npr,pow=None,als=None) • get spin colour correlation rcl (npr,i1,i2,pow=None,als=None) For all of these functions the difference is due to the new treatment of powers in Recola2 and the backward compatibility with Recola, as described in Section 4.3. The argument pow, which is overloaded in the Fortran95 interface, is replaced in Python by the keyword arguments pow and gs (or als). 15 The functions are called in the usual way with the exception that either pow or gs/als is passed and labelled explicitly, e.g.: A2 = pyrecola.get_squared_amplitude_rcl(..., pow= [2,4]) A2 = pyrecola.get_squared_amplitude_rcl(..., als=1)

Missing subroutines
The subroutines get colour configurations rcl (Section 4.5.5 in Ref. [14]) and get helicity configurations rcl (Section 4.5.6 in Ref. [14]) are currently not included in the Python interface. The authors are willing to provide a custom solution, upon request, to include their functionality.

Conclusions
The Recola2 library computes amplitudes in the Standard Model of particle physics including QCD and electroweak interaction and in general quantum field theories at the tree and one-loop level with no a-priori restriction on the particle multiplicities, once corresponding model files are available. Amplitudes can be obtained for specific colour structures and helicities and squared amplitudes with or without summation/average over helicities. We provide subroutines for the computation of colour-and spin-correlated leading-order squared amplitudes that are required in the dipole subtraction formalism. Furthermore, the code supports the selection of resonant contributions allowing for the computation of factorizable corrections in pole approximations.
In this first release of Recola2 we include Recola2 model files for the computation of processes in the Two-Higgs-Doublet Model and the Higgssinglet extension of the Standard Model. The model files are generated in the complex-mass scheme, and various renormalization schemes are supported for the electromagnetic coupling, the strong coupling and additional parameters in extended Higgs sectors.
The present version of Recola2 is restricted to theories with scalars, Dirac fermions and vector bosons. An enhanced version with Majoranafermion support and further Recola2 model files, including anomalous couplings, is in preparation.