# 5.6. Processes¶

In addition to the general matrix-element calculation settings specified as
described in Matrix elements, the hard scattering process has to be
defined and further process-specific calculation settings can be specified.
This happens in the `PROCESSES`

part of the input file and is described in
the following section.

A simple example looks like:

```
PROCESSES:
- 93 93 -> 11 -11 93{4}:
Order: {QCD: 0, EW: 2}
CKKW: 20
```

In general, the process setup takes the following form:

```
PROCESSES:
# Process 1:
- <process declaration>:
<parameter>: <value>
<multiplicities-to-be-applied-to>:
<parameter>: <value>
...
# Process 2:
- <process declaration>
...
```

i.e. `PROCESSES`

followed by a list of process definitions.

Each process definition starts with the declaration of the (core) process itself. The initial and final state particles are specified by their PDG codes, or by particle containers, see Particle containers. Examples are

`- 93 93 -> 11 -11`

Sets up a Drell-Yan process group with light quarks in the initial state.

`- 11 -11 -> 93 93 93{3}`

Sets up jet production in e+e- collisions with up to three additional jets.

Special features of the process declaration will be documented in the following. The remainder of the section then documents all additional parameters for the process steering, e.g. the coupling order, which can be nested as `key: value`

pairs within a given process declaration.

An advanced syntax feature shall be mentioned already here, since it will be used in some of the examples in the following: Most of the parameters can be grouped under a multiplicity key, which can
either be a single or a range of multiplicities, e.g. ```
2->2-4: {
<settings for 2->2, 2->3 and 2->4 processes> }
```

. The usefulness of this will hopefully become clear in the examples in the following.

## 5.6.1. Special features of the process declaration¶

### 5.6.1.1. PDG codes¶

Initial and final state particles are specified using their PDG codes
(cf. PDG). A
list of particles with their codes, and some of their properties, is
printed at the start of each Sherpa run, when the OUTPUT is set
at level `2`

.

### 5.6.1.2. Particle containers¶

Sherpa contains a set of containers that collect particles with similar properties, namely

lepton (carrying number

`90`

),neutrino (carrying number

`91`

),fermion (carrying number

`92`

),jet (carrying number

`93`

),quark (carrying number

`94`

).

These containers hold all massless particles and anti-particles of the denoted type and allow for a more efficient definition of initial and final states to be considered. The jet container consists of the gluon and all massless quarks, as set by

```
PARTICLE_DATA:
<id>:
Mass: 0
# ... and/or ...
Massive: false
```

A list of particle containers is printed at the start of each Sherpa
run, when the OUTPUT is set at level `2`

.

It is also possible to define a custom particle container using the
keyword `PARTICLE_CONTAINER`

. The container must be given an
unassigned particle ID (kf-code) and its name (freely chosen by you)
and the flavour content must be specified. An example would be the
collection of all down-type quarks using the unassigned ID 98, which
could be declared as

```
PARTICLE_CONTAINER:
98:
Name: downs
Flavours: [1, -1, 3, -3, 5, -5]
```

Note that, if wanted, you have to add both particles and anti-particles.

### 5.6.1.3. Parentheses¶

The parenthesis notation allows to group a list of processes with different flavor content but similar structure. This is most useful in the context of simulations containing heavy quarks. In a setup with massive b-quarks, for example, the b-quark will not be part of the jets container. In order to include b-associated processes easily, the following can be used:

```
PARTICLE_DATA:
5: {Massive: true}
PARTICLE_CONTAINER:
98: {Name: B, Flavours: [5, -5]}
PROCESSES:
- 11 -11 -> (93,98) (93,98):
...
```

### 5.6.1.4. Curly brackets¶

The curly bracket notation when specifying a process allows up to a
certain number of jets to be included in the final state. This is
easily seen from an example, `11 -11 -> 93 93 93{3}`

sets
up jet production in e+e- collisions. The matix element final state
may be 2, 3, 4 or 5 light partons or gluons.

## 5.6.2. Decay¶

Specifies the exclusive decay of a particle produced in the matrix element. The virtuality of the decaying particle is sampled according to a Breit-Wigner distribution. In practice this amounts to selecting only those diagrams containing s-channels of the specified flavour while the phase space is kept general. Consequently, all spin correlations are preserved. An example would be

```
- 11 -11 -> 6[a] -6[b]:
Decay:
- 6[a] -> 5 24[c]
- -6[b] -> -5 -24[d]
- 24[c] -> -13 14
- -24[d] -> 94 94
```

## 5.6.3. DecayOS¶

Specifies the exclusive decay of a particle produced in the matrix
element. The decaying particle is on mass-shell, i.e. a strict
narrow-width approximation is used. This tag can be specified
alternatively as `DecayOS`

. In practice this amounts to
selecting only those diagrams containing s-channels of the specified
flavour and the phase space is factorised as well. Nonetheless, all
spin correlations are preserved. An example would be

```
- 11 -11 -> 6[a] -6[b]:
DecayOS:
- 6[a] -> 5 24[c]
- -6[b] -> -5 -24[d]
- 24[c] -> -13 14
- -24[d] -> 94 94
```

## 5.6.4. No_Decay¶

Remove all diagrams associated with the decay/s-channel of the given flavours. Serves to avoid resonant contributions in processes like W-associated single-top production. Note that this method breaks gauge invariance! At the moment this flag can only be set for Comix. An example would be

```
- 93 93 -> 6[a] -24[b] 93{1}:
Decay: 6[a] -> 5 24[c]
DecayOS:
- 24[c] -> -13 14
- -24[b] -> 11 -12
No_Decay: -6
```

## 5.6.5. Scales¶

Sets a process-specific scale. For the corresponding syntax see SCALES.

## 5.6.6. Couplings¶

Sets process-specific couplings. For the corresponding syntax see COUPLINGS.

## 5.6.7. CKKW¶

Sets up multijet merging according to [HKSS09]. The additional argument specifies the parton separation criterion (“merging cut”) Q_{cut} in GeV. It can be given in any form which is understood by the internal interpreter, see Interpreter. Examples are

Hadronic collider:

`CKKW: 20`

Leptonic collider:

`CKKW: pow(10,-2.5/2.0)*E_CMS`

DIS:

`CKKW: $(QCUT)/sqrt(1.0+sqr($(QCUT)/$(SDIS))/Abs2(p[2]-p[0]))`

## 5.6.8. Process_Selectors¶

Using `Selectors: [<selector 1>, <selector 2>]`

in a process
definition sets up process-specific selectors. They use the same
syntax as describes in Selectors.

## 5.6.9. Order¶

Sets a process-specific coupling order. Orders are counted at the
amplitude level. For example, the process 1 -1 -> 2 -2 would have
orders `{QCD: 2, EW: 0`

}, `{QCD: 1, EW: 1}`

and ```
{QCD: 0,
EW: 2}
```

. There can also be a third entry that is model specific
(e.g. for HEFT couplings). Half-integer orders are so far supported
only by Comix. The word “Any” can be used as a wildcard.

Note that for decay chains this setting applies to the full process, see Decay and DecayOS.

## 5.6.10. Max_Order¶

Sets a process-specific maximum coupling order. See Order for the syntax and additional information.

## 5.6.11. Min_Order¶

Sets a process-specific minimum coupling order. See Order for the syntax and additional information.

## 5.6.12. Min_N_Quarks¶

Limits the minimum number of quarks in the process to the given value.

## 5.6.13. Max_N_Quarks¶

Limits the maximum number of quarks in the process to the given value.

## 5.6.14. Min_N_TChannels¶

Limits the minimum number of t-channel propagators in the process to the given value.

## 5.6.15. Max_N_TChannels¶

Limits the maximum number of t-channel propagators in the process to the given value.

## 5.6.16. Print_Graphs¶

Writes out Feynman graphs in LaTeX format. The parameter specifies a directory name in which the diagram information is stored. This directory is created automatically by Sherpa. The LaTeX source files can be compiled using the command

```
$ ./plot_graphs <graphs directory>
```

which creates an html page in the graphs directory that can be viewed in a web browser.

## 5.6.17. Name_Suffix¶

Defines a unique name suffix for the process.

## 5.6.18. Integration_Error¶

Sets a process-specific relative integration error target. An example to specify an error target of 2% for 2->3 and 2->4 processes would be:

```
- 93 93 -> 93 93 93{2}:
2->3-4:
Integration_Error: 0.02
```

## 5.6.19. Max_Epsilon¶

Sets epsilon for maximum weight reduction. The key idea is to allow weights larger than the maximum during event generation, as long as the fraction of the cross section represented by corresponding events is at most the epsilon factor times the total cross section. In other words, the relative contribution of overweighted events to the inclusive cross section is at most epsilon.

## 5.6.20. NLO_Mode¶

This setting specifies whether and in which mode an NLO calculation should be performed. Possible values are:

`None`

perform a leading-order calculation (this is the default)

`Fixed_Order`

perform a fixed-order next-to-leading order calculation

`MC@NLO`

perform an MC@NLO-type matching of a fixed-order next-to-leading order calculation to the resummation of the parton shower

The usual multiplicity identifier applies to this switch as well.
Note that using a value other than `None`

implies `NLO_Part: BVIRS`

for
the relevant multiplicities.
For fixed-order NLO calculations (`NLO_Mode: Fixed_Order`

), this can be
overridden by setting `NLO_Part`

explicitly, see NLO_Part.

Note that Sherpa includes only a very limited selection of one-loop corrections. For processes not included external codes can be interfaced, see External one-loop ME

## 5.6.21. NLO_Part¶

In case of fixed-order NLO calculations this switch specifies which pieces of a NLO calculation are computed, also see NLO_Mode. Possible choices are

`B`

born term

`V`

virtual (one-loop) correction

`I`

integrated subtraction terms

`RS`

real correction, regularized using Catani-Seymour subtraction terms

Different pieces can be combined in one processes setup. Only pieces with the same number of final state particles and the same order in alpha_S and alpha can be treated as one process, otherwise they will be automatically split up.

## 5.6.22. NLO_Order¶

Specifies the relative order of the NLO correction wrt. the considered
Born process. For example, `NLO_Order: {QCD: 1, EW: 0}`

specifies
a QCD correction while `NLO_Order: {QCD: 0, EW: 1}`

specifies an
EW correction.

## 5.6.23. Subdivide_Virtual¶

Allows to split the virtual contribution to the total cross section
into pieces. Currently supported options when run with
BlackHat are
`LeadingColor`

and `FullMinusLeadingColor`

. For
high-multiplicity calculations these settings allow to adjust the
relative number of points in the sampling to reduce the overall
computation time.

## 5.6.24. ME_Generator¶

Set a process specific nametag for the desired tree-ME generator, see ME_GENERATORS.

## 5.6.25. RS_ME_Generator¶

Set a process specific nametag for the desired ME generator used for the real minus subtraction part of NLO calculations. See also ME_GENERATORS.

## 5.6.26. Loop_Generator¶

Set a process specific nametag for the desired loop-ME generator. The
only Sherpa-native option is `Internal`

with a few hard coded loop
matrix elements. Other loop matrix elements are provided by external
libraries.

## 5.6.27. Associated_Contributions¶

Set a process specific list of associated contributions to be computed.
Valid values are `EW`

(approximate EW corrections),
`LO1`

(first subleading leading-order correction),
`LO2`

(second subleading leading-order correction),
`LO3`

(third subleading leading-order correction).
They can be combined, eg. @code{[EW, LO1, LO2, LO3]}.
Please note, the associated contributions will not be
added to the nominal event weight but instead are available to
be included in the on-the-fly calculation of alternative event
weights, cf. Associated contributions variations.

## 5.6.28. Integrator¶

Sets a process-specific integrator, see INTEGRATOR.

## 5.6.29. PSI_ItMin¶

Sets the number of points per optimization step, see PSI.

## 5.6.30. RS_PSI_ItMin¶

Sets the number of points per optimization step in real-minus-subtraction parts of fixed-order and MC@NLO calculations, see PSI.

## 5.6.31. Special Group¶

Note

Needs update to Sherpa 3.x YAML syntax.

Allows to split up individual flavour processes within a process group for integrating them separately. This can help improve the integration/unweighting efficiency. Note: Only works with Comix so far. Example for usage:

```
Process 93 93 -> 11 -11 93
Special Group(0-1,4)
[...]
End process
Process 93 93 -> 11 -11 93
Special Group(2-3,5-7)
[...]
End process
```

The numbers for each individual process can be found using a script in
the AddOns directory: `AddOns/ShowProcessIds.sh Process/Comix.zip`

## 5.6.32. Event biasing¶

In the default event generation mode, events will be distributed “naturally” in the phase space according to their differential cross sections. But sometimes it is useful, to statistically enhance the event generation for rare phase space regions or processes/multiplicities. This is possible with the following options in Sherpa. The generation of more events in a rare region will then be compensated through event weights to yield the correct differential cross section. These options can be applied both in weighted and unweighted event generation.

### 5.6.32.1. Enhance_Factor¶

Factor with which the given *process/multiplicity* should be statistically
biased. In the following example, the Z+1j process is generated 10 times more
often than naturally, compared to the Z+0j process. Each Z+1j event will thus
receive a weight of 1/10 to compensate for the bias.

```
- 93 93 -> 11 -11 93{1}:
2->3:
Enhance_Factor: 10.0
```

### 5.6.32.2. RS_Enhance_Factor¶

Sets an enhance factor (see Enhance_Factor) for the RS-piece of an MC@NLO process.

### 5.6.32.3. Enhance_Function¶

Specifies a phase-space dependent biasing of parton-level events (before showering). The given parton-level observable defines a multiplicative enhancement on top of the normal matrix element shape. Example:

```
- 93 93 -> 11 -11 93{1}:
2->3:
Enhance_Function: VAR{PPerp2(p[2]+p[3])/400}
```

In this example, Z+1-jet events with \(p_\perp(Z)=20\) GeV and Z+0-jet events will come with no enhancement, while other Z+1-jet events will be enhanced with \((p_\perp(Z)/20)^2\). Note: if you would define the enhancement function without the normalisation to \(1/20^2\), the Z+1-jet would come with a significant overall enhancement compared to the unenhanced Z+0-jet process, which would have a strong impact on the statistical uncertainty in the Z+0-jet region.

Optionally, a range can be specified over which the multiplicative biasing should be applied. The matching at the range boundaries will be smooth, i.e. the effective enhancement is frozen to its value at the boundaries. Example:

```
- 93 93 -> 11 -11 93{1}:
2->3:
Enhance_Function: VAR{PPerp2(p[2]+p[3])/400}|1.0|100.0
```

This implements again an enhancement with \((p_\perp(Z)/20)^2\) but only in the range of 20-200 GeV. As you can see, you have to be take into account the normalisation also in the range specification.

### 5.6.32.4. Enhance_Observable¶

Specifies a phase-space dependent biasing of parton-level events (before showering). Events will be statistically flat in the given observable and range. An example would be:

```
- 93 93 -> 11 -11 93{1}:
2->3:
Enhance_Observable: VAR{log10(PPerp(p[2]+p[3]))}|1|3
```

Here, the 1-jet process is flattened with respect to the logarithmic transverse momentum of the lepton pair in the limits 1.0 (10 GeV) to 3.0 (1 TeV). For the calculation of the observable one can use any function available in the algebra interpreter (see Interpreter).

The matching at the range boundaries will be smooth, i.e. the effective enhancement is frozen to its value at the boundaries.

This can have unwanted side effects for the statistical uncertainty when used in a multi-jet merged sample, because the flattening is applied in each multiplicity separately, and also affects the relative selection weights of each sub-sample (e.g. 2-jet vs. 3-jet).

Note

The convergence of the Monte Carlo integration can be worse if enhance functions/observables are employed and therefore the integration can take significantly longer. The reason is that the default phase space mapping, which is constructed according to diagrammatic information from hard matrix elements, is not suited for event generation including enhancement. It must first be adapted, which, depending on the enhance function and the final state multiplicity, can be an intricate task.

If Sherpa cannot achieve an integration error target due to the use of enhance functions, it might be appropriate to locally redefine this error target, see Integration_Error.