Draft

From Wiki Les Houches 09

Revision as of 08:16, 13 June 2009 by Daniel (Talk | contribs)
Jump to: navigation, search

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


Contents

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
mode leading color
model_file my_favorite_model_in_LH_format.slh

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 importancce difference between the provided subcontributions. The integer label will be use at run time to identify the subprocesses.

Example contract file

# example contract file
# contract produced by OLE HAPPY_OLE

QCD_scheme Dreg                                 | 1  
mode leading color                              | 1
model_file my_favorite_model_in_LH_format.slh   | 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"

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

Possibly useful links

http://arnholm.org/software/cppf77/cppf77.htm

Personal tools