From Wiki Les Houches 09

(Difference between revisions)
Jump to: navigation, search
(order file)
(order file)
Line 50: Line 50:
  scheme Dreg
  scheme Dreg
  mode leading color
  mode leading color
<br />
  CH_SUMMED 2 -> 3 21 21 6 -6 21
  CH_SUMMED 2 -> 3 21 21 6 -6 21
  CH_SUMMED 2 -> 3 1 -1 6 -6 21
  CH_SUMMED 2 -> 3 1 -1 6 -6 21

Revision as of 07:23, 13 June 2009

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".

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.

Here is an example of a order file

scheme Dreg
mode leading color

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

Possibly useful links


Personal tools