# Automated ME/PS merging

### From Wiki Les Houches 09

(→Open questions) |
(→Introduction) |
||

Line 1: | Line 1: | ||

== Introduction == | == Introduction == | ||

- | Within the partonshower Monte Carlos, as well as in standalone projects such as POWHEG, progress is being made to automize the matching to fixed order (NLO) QCD calculations, as well as to automize plain matrix element corrections, which | + | Within the partonshower Monte Carlos, as well as in standalone projects such as POWHEG, progress is being made to automize the matching to fixed order (NLO) QCD calculations, as well as to automize plain matrix element corrections, which correct the hardest partonshower emission to the exact real emission matrix element. |

In order to use existing and future tools automating fixed-order calculations, we see a demand to have a general interface such that partonshower or dedicated matching codes can access the building blocks of a fixed-order calculation in a unified way. | In order to use existing and future tools automating fixed-order calculations, we see a demand to have a general interface such that partonshower or dedicated matching codes can access the building blocks of a fixed-order calculation in a unified way. |

## Revision as of 10:20, 15 June 2009

## Contents |

## Introduction

Within the partonshower Monte Carlos, as well as in standalone projects such as POWHEG, progress is being made to automize the matching to fixed order (NLO) QCD calculations, as well as to automize plain matrix element corrections, which correct the hardest partonshower emission to the exact real emission matrix element.

In order to use existing and future tools automating fixed-order calculations, we see a demand to have a general interface such that partonshower or dedicated matching codes can access the building blocks of a fixed-order calculation in a unified way.

Within the context of present approaches a runtime interface, i.e. an Appliation Programming Interface (API) is needed, allowing the matching code to link the fixed-order code statically or dynamically.

This approach shows overlap with the efforts of interfacing oneloop codes and Monte Carlo frameworks, but is to be seen in a more general context abstracting from the details how exactly the fixed-order calculation is being carried out. A combined effort should therefore be made.

We assume that NLO calculations are carried out in a subtraction framework, where each subtraction term is a function of the real emission kinematics but being valued in observables defined on the 'underlying Born configuration', which is obtained through a mapping inherent to the subtraction scheme chosen and may vary for each individual subtraction term.

### What the interface should not:

- Limit the way the fixed-order performs its calculations
- Limit the way a partonshower or matching code carries out matching and/or matrix element corrections
- Force anyone to stick to a particular programming model or language

### What the interface should:

- Abstract the buidling blocks of a fixed-order calculation to be accessible as black boxes by a partonshower or matching code.
- Being specified in a language independent way, with bindings to be provided (at least FORTRAN and C/C++)

## A proposal specification

### Notation

The interface is formulated as a set of functions, taking any number of arguments and returning a result. The result may be a composite object of several types, which, depending on the language binding, may individually be passed as references to the function call.

A function of name foo taking arguments of type A1,A2,..., returning a result of type T is denoted by T foo (A1,A2,...), where each argument may be followed by a name identifying the meaning of the argument.

The required types are defined in the following section, except for obvious simple types.

### Types used

**vector** - A list of objects of the same type. Elements in the list can be accessed randomly by an integer index. The type of objects stored is indicated in ange brackets, e.g. vector<double> is a vector storing doubles. The size of the vector is to be asserted in the context of a particular piece of the interface.

Examples: INTEGER V(4), std::vector<int> v

**pair** - A pair stores to values of potentially different type. This is an auxiliary concept which does not have to be supported by a particular language. A pair storing values of type T1 and T2, resepctively, is denoted pair<T1,T2>.

**processid** - Defined to be vector<int>. Identifies a subprocess giving PDG ids for incoming partons in the first two entries, and PDG ids for outgoing partons in the following entries. The size of the vector is guaranteed to be greater or equal to three.

Example: gg -> d dbar g would be identified by the entries {21,21,1,-1,21}.

**momentum** - Defined to be vector<double> of length five. The first four entries contain the four-momentum components px,py,pz,E in units of GeV. The fifth component is optional containing the invariant mass squared in units of GeV squared. The metric is agreed to be mostly-minus,

**pspoint** - Defined to be pair<double,vector<momentum>>. Represents a phasespace point as the phasespace weight (Jacobian from unit-hypercube random numbers to phasespace measure) and a set of momenta. The first two momentum entries specify the momenta of incoming partons, subsequent these of outgoing partons. The size of the momentum vector is greater or equal to three. The weight is given in units of the proper power of GeV to obtain a dimensionless quantity.

**colourflow** - Defined to be vector<pair<int,int>> . Represents a colour flow assigned to a particular subprocess in the following convention: in association to a processid, the first and second members of an entry of a colourflow at position i contain an integer id for the colour and anticolour line, the corresponding parton at position i in the process id is connected to. By convention, a triplet always has its second colour index set to zero, an antitriplet its first index. A singlet uses the pair {0,0}. Note that this notation is not limited to large-Nc flows, but may represent any basis tensor in the fundamental representation by the following identification: Each non-zero entry in the first entry of a pair in a colour flow vector identifies an index in the fundamental, each entry at the second position an index in the anti-fundamental representation and entries of the same id are attached to a Kronecker-delta. Thus, the 1/Nc supressed singlet contribution to a gluon carries the pair {k,k}, where k is not zero.

Example: suppose the colourflows {{0,0},{0,0},{1,0},{0,2},{2,1}} and {{0,0},{0,0},{1,0},{0,1},{2,2}} are associated to the processid {-11,11,1,-1,21} (e+e- -> d dbar g), then the first one is a large-Nc flow corresponding to , the second one a supressed flow corresponding to .

### Initialization

**bool initialize ()** - The fixed-order code performs intialization and reads any relevant parameters from its preferred input mechanism. It returns true on success and false on failure.

### Bookkeeping

**pair<int,string> alphasinfo ()** - Return information on the running of the strong coupling to be used as a combination of the number of loops contributing to the QCD beta function, and a string identifying the renormalization scheme used. Vaues for the latter have to be agreed on.

**bool haveleadingorder (processid)** - Return true, if the process identified by the given processid can be calculated at leading order.

**vector<colourflow> colourflows (processid)** - Return the possible colourflows which could be selected for the given processid.

**vector<colourflow> largencolourflows (processid)** - Return the possible colourflows in the large-Nc limit which could be selected for the given processid.

**bool haveoneloop (processid)** - Return true, if oneloop QCD corrections to the given process can be calculated.

**string havesubtraction (processid)** - Return a non-empty string identifying a subtraction scheme, if real emission subtraction terms are available for the given process. This does not require that the real emission process itself can be calculated. Return an empty string, if subtraction terms are not present. Other return values have to be agreed on.

**vector<processid> realemissions (processid)** - Assuming the given processid identifies a Born process, return the real emission processes to be considered for a NLO QCD correction.

**vector<int> subtractions (processid)** - Assuming the given processid identifies a real emission process, return a list of ids for the subtraction terms to be considered. The ids need to be unique to the fixed-order code and are not used except for identifying a subtraction term. For dynamically allocated vectors, the function may return an empty vector to indicate that the process considered is non-singular, for fixed-size vectors it should indicate this by filling the vector with zeroes.

**processid underlyingborn (processid, int)** - Given a real emission process id and subtraction term id through the first and second arguments, respectively, return the underlying Born process the subtraction term maps to.

**pair<int,int> collinearlimit (processid, int)** - Given a real emission process id and subtraction term id through the first and second arguments, respectively, return the positions of the partons in the processid given, for which the identified subtraction term subtracts the collinear singularity. The ordering of the returned value is irrelevant and by convention fixed such that the first entry is less than the second.

### Kinematics and phasespace

**int ndim (processid)** - Return the number of random numbers needed to generate a phasespace point for the given process.

**pspoint phasespace (pair<momentum,momentum>, vector<double>, processid)** - Generate a phasespace point given incoming particle's momenta, a list of random numbers and a process id.

**pspoint collinearphasespace (pair<momentum,momentum>, vector<double>, processid, int)** - Generate a phasespace point for the convolution of the finite collinear remainder with the Born process. Arguments in order are incoming particle momenta, random numbers (one additional random number wrt the Born phasespace is provided), the process and an id for the first (0) or second (1) incoming parton to be considered.

### Dynamics

**double me2 (processid, vector<momentum>, double)** - Return the helicity and colour summed matrix element squared for the given process, phasespace point and value of alphas. The result is given in units of the proper power of inverse GeV to obtain a dimensionless quantity.

**double partialme2 (processid, vector<momentum>, double, colourflow)** - Return the helicity summed partial amplitude squared, identified by the given colour flow, evaluated for the given processid, phasespace point and value of alphas.

**double bornvirt (processid, vector<momentum>, double, double)** - Return the helicity and colour summed Born-virtual interference plus the integraded subtraction terms (i.e. the finite part remaining after carrying out subtraction), consistent with the subtraction scheme chosen for the real emissions. Arguments in order are the process to be considered, the phasespace point, the value of alphas and the renormalization scale in GeV. The result is given in units of the proper power of inverse GeV to obtain a dimensionless quantity.

**double subtraction (processid, int, vector<momentum>, double)** - Return the subtraction term identified by real emission process and subtraction term id, given a phasespace point and vaue of alphas. The result is defined such that the phasespace weight and parton luminosity relevant for the real emission process times the returned value constitutes the weight for the differential subtraction cross section. The result is given in units of the proper power of inverse GeV to obtain a dimensinoaless quantity.

### Open questions

- In addition to the functionality defined above, interested has been raised in accessing colour correlated and helicity amplitudes, or individual partial amplitudes in a colour decomposition to be agreed on, to facilitate automized subtractions. This would also need to have unsubtracted virtual corrections as coefficients of the Laurent series in epsilon. The interface needs extensions here, which however generate huge overlap with the efforts of interfacing oneloop engines and real emission frameworks.

- Generalizing to include decays

--SimonPlaetzer 09:35, 15 June 2009 (UTC)