# Draft

This is a working draft for an interface between one-loop amplitude programs and monte carlo programs.

## Goal of the interface

The goal of the interface is to facilitate the transfer of information between one-loop programs (which we will call one-loop provider OLP or one-loop engine depending on whether we mean the method/work (Golem, Rocket, Helac one-loop, BlackHat, ...) or the actual run time entity) which provide one-loop matrix element and the program the does the integration over the phasespace (which we will call MC).

## Model of the interaction between MC and OLE

The model of the interaction between the MC and OLE assumes two phases which we will call "initialization" and "run time".

1. Initialization

During this phase the MC sets up the OLE. This means setting up the parameters and fixing options that are offered by the OLP

• masses, width
• operating mode, for example which approximation (leading color, massless b's, ...)
• schemes (renormalization, factorization)

2. Run time

During this phase the MCP queries the OLE for the value of a virtual matrix element.

# Implementation proposal

This section outlines a proposal for the implementation of the interface model presented above. The aim is to make it easy to implemeent it in all common programming language. The functions will be called by the MCP and executed by the OLE. The name of the function and its implementation can be chosen by the OLP (although sticking to the name in this wiki would be convenient), the main point being to provide a function that satisfies the interface.

In the easiest case of merging two programs written in the same language, the connection between the caller (the MCP) and the receiver (the OLE) can be easily achieved by linking the rogram together. In more difficult cases with mixed languages or special environments a bridge program or transmission protocol will have to be put in place. This is however not the topic or concern of this proposal, here we only want to ensure that the end point of these bridges will be the same.

## Initialisation phase

In this phase the MCP creates a file that contains the information about the subprocesses it will need to perform the computation. We will call this file the "order". This file is then read by the OLE and it creates a new file with the agreement about how to link the MCP and OLE at runtime is provided. We will call this file a "contract". Lines starting with a # character are treated as comments. In this section we call a subprocess both the partonic subprocesses and any component of if in some basis.

### order file

the order file contains the information needed for the OLE to declare whether or not it can provide the subprocess the MCP wants.

The first part of the file contains some general settings.

The second part contains the list of the subprocesses the MCP needs. Each line is of the form

[TYPE] [in] -> [out] [[PDG]...] [...]


where [TYPE] describes which type of subprocess the MCP want. For example one could ask for color and helicity summed amplitudes. [in] is the number of particles in the initial state. [out] is the number of particles in the final state. [PDG] is the pdg code of the particle. The first entries are for the initial states, then comes the final state particles.

The settings that a OLE should (have to?) provide are

• QCD_scheme : the scheme for the QCD renormalization
• EW_scheme : the scheme for the EW renormalization

OLE can provide more settings. They have to be documented. We encourage OLP to submit new settings to the WIKI in order to avoid having the same optional setting called differently by different OLP.

• model_file : the model file (in LH format) from which parameters have to be read
• mode : the operating mode of the

The OLE can provide defaults for the settings it provides.

Here is an example of a order file

# example contract file

QCD_scheme Dreg
model_file my_favorite_model_in_LH_format.slh
mode subdivide_subprocess yes

CH_SUMMED 2 -> 3 21 21 6 -6 21
CH_SUMMED 2 -> 3 1 -1 6 -6 21
CH_SUMMED 2 -> 3 1 21 6 -6 1


### contract file

The OLE reads the order file and creates its "answer" in the form of a contract file. The contract file is basically a copy of the order file, but with information from the OLE appended at the end of each (non content-free) line. The OLE answer is separated from the MCP "request" by a "|" character. The answer of the OLE should give are explained in the following paragraphs.

setting: 1 if the setting is supported and the supplied arguments are correct. Errors are coded as follows: -1 if the option is not supported, -2 if the option is supported but the parameter is not recognized/valid.

For subprocesses, the answer should be the number of separate contributions that the OLE can compute that add up to the required subprocess, followed by an integer label that identifies each of these contributions. This allows the multi-channel integrator (if present) to take advantage of importance difference between the provided subcontributions. The integer label will be use at run time to identify the subprocesses. OLE that provide this kind of separation might also provide a single subprocess that is the sum of all contributions. Whether or not to return the contributions separately could be set using a setting subdivide_subprocess

Example contract file

# example contract file
# contract produced by OLE HAPPY_OLE

QCD_scheme Dreg                                 | 1
model_file my_favorite_model_in_LH_format.slh   | 1
subdivide_subprocess yes                        | 1

CH_SUMMED 2 -> 3 21 21 6 -6 21                  | 2 13 35
CH_SUMMED 2 -> 3 1 -1 6 -6 21                   | 1 29
CH_SUMMED 2 -> 3 1 21 6 -6 1                    | 3 8 23 57



It would be useful if the OLE could provide some help at this point (like listing the parameter that are accepted).

# example contract file
# contract produced by OLP UNHAPPY_OLE

QCD_scheme Dreg                                 | -2 note: supported schemes are t'HV
mode leading color                              | -2 note: OLE UNHAPPY don't have a "leading color" mode
model_file my_favorite_model_in_LH_format.slh   | -2 note: could not find file "my_favorite_model_in_LH_format.slh"
subdivide_subprocess yes                        | -1 note: unknown setting

CH_SUMMED 2 -> 3 21 21 6 -6 21                  | 0 note: Sorry, OLE don't support massive quarks
CH_SUMMED 2 -> 3 1 -1 6 -6 21                   | 0 note: Sorry, this process is not implemented in OLE UNHAPPY
CH_SUMMED 2 -> 3 1 21 6 -6 1                    | 0 note: Sorry, too hard for OLE UNHAPPY


A description of the difference between the different contributions could be useful :

CH_SUMMED 2 -> 3 21 21 6 -6 21                  | 2 4 25 note: contributions are leading_color, sub_leading_color


## Run time phase

To start the run time phase, the OLE might need to be reminded of the contract it committed to (this is the case for programs that dynamically generate their evaluation structure as opposed to libraries of generated code). To initialize the OLE for the run, the function Init has to be called by the MCP. After this the MCP can start querying the OLE fr the subprocesses. This is done using the function EvalSubProcess.

### Init

the function Init should be passed an character sting that contains the name of the contract file. The function returns 1 if the initialization is successful, 0 if not.

### EvalSubprocess

The parameters to be passed to the EvalSubprocess function are (to avoid confusing, please use this order)

• the integer label of the subprocess
• the address of the start of an array containing the components of the momenta. The momenta are placed in a on dimensional array. The first component is the energy of the first particle, then x, y, z components of this momentum and its mass, then comes the second momentum energy, x, y, z, m etc... The mass is defined as E^2-x^2-y^2-z^2 but is provided for numerical reasons. The unit is Gev. Both incoming and outgoing momenta have a positive energy. This means that the array will contain n*5 double precision numbers.
• the renormalization scale as a double precision number, in Gev.
• the strong coupling double alpha_s
• the weak coupling alpha_EW
• the address of a the array where the result is to be put. The length and the content of this array is to be documented by the OLP. We will define here one possibility, if the OLP departs from it, it should be clearly documented.
Pole2, Pole1, Pole0, Born


where PoleN is the real part of the interference $Re\left|(A_1) A_0^*\right|$