VINCIA Merging Settings

Sector Merging (MESS) -- VINCIA only

Matrix Elements
Process Specification
Merging Scale
Merging in Resonance Systems (Unvalidated)
Treatment of QED (and other non-QCD) Corrections

The VINCIA sector shower employs its own CKKW-L merging scheme, which differs from the one implemented for the simple showers or Dire. The biggest difference is that (for gluon emissions) the VINCIA sector shower only possesses a single history (or branching tree), i.e., any given configuration produced by it can be uniquely traced back to every intermediate state the shower has produced on the way. While for gluon splittings, all possible quark permutations need to be taken into account, the VINCIA sector shower is still "maximally bijective", i.e., it has the lowest possible number of histories. MESS merging can therefore be viewed as a midpoint between the CKKW-L and the CKKW scheme, as only a single, deterministic history needs to be generated, which nevertheless exactly reflects the shower history and Sudakov factors are generated dynamically using trial showers. As such, it is specifically designed for merging with high-multiplicity matrix elements.

VINCIA's merging may be enabled by using the VINCIA sector shower and switching merging on:

 
PartonShowers:model = 2 
Vincia:sectorShower = on 
Merging:doMerging = on

In addition, the user should set

 
Vincia:kineMapFFsplit = 1

since the inverse kinematic map for other splitting maps are not currently available. We also advise running with

 
Check:abortIfVeto = on

such that any errors which occur during merging will be flagged as an aborted event (rather than a zero weight event for normally vetoed events).

We note that, different to merging with the simple showers, Merging:doMerging should always be set to on to enable merging, no matter which merging scale definition is used.

MESS merging can generally replace CKKW-L merging with the simple showers and is illustrated in the main program main280.cc. However, also other tree-level merging main programs can be used with the modifications to the command files as outlined below.

Matrix Elements

As for merging with the simple showers, the user has to provide LHE files with pre-generated events with up to N additional jets. The maximal number of additional jets relative to the Born that do not arise from resonance decays is specified by setting

 
Merging:nJetMax = N

Process Specification

The hard process should be specified through Merging:Process, using the following rules:

The whole string should be encased in curly brackets, { ... }.
Specify particles one at a time, separated by whitespace, using Pythia's naming conventions in ParticleData.
The intial and final state should be separated by >.
Exactly two initial state particles should be specified
Resonance decays may be specifed also using >, but if there is more than one particle in the intermediate final state it should be encased in round brackets, ( ... ). In principle as many nested decays may be specified as required, with additional brackets for each decay. However, we make no claims on how physically sensible merging in such systems is.
Resonances must decay to exactly 2 particles.
In addition to Pythia's naming scheme, the following "multiparticles" are defined:
- p=p+=pbar=p-=n=nbar=j={1,2,3,4,5,-1,-2,-3,-4,-5,21}
- q=Q=QUARK={1,2,3,4,5}
- qbar=QBAR=ANTIQUARK={-1,-2,-3,-4,-5}
- LEPTONS={11,-11,13,-13,15,-15}
- l+={-11,-13,-15}
- l-={11,13,15}
- NEUTRINOS={12,-12,14,-14,16,-16}
- nu={12,14,16}
- nubar={-12,-14,-16}
- gammaZ={22,23}

We note that the option Merging:Process = guess is not supported, as we believe that the user should be fully aware and in control of what the hard process in the event is.

VBF and HEFT

Following the idea that the user needs to specify the event topology exactly, the following two switches can be used to further refine the process:

flag Vincia:MergeVBF (default = off)
Experimental switch to enable merging in VBF processes.

flag Vincia:MergeHEFT (default = off)
Experimental switch to consider HEFT couplings in the history construction.

Merging Scale

MESS merging presently supports three different merging scale definitions. If only Merging:doMerging = on is set, the shower evolution variable (a generalised Ariadne pT) is used to define the merging scale. Additionally, the merging scale may be defined in terms of a kT cut by setting

 
Merging:doKTMerging = on

and (optionally) specifying Merging:ktType, see CKKW-L Merging for details. In both cases, the merging scale should be specified through Merging:TMS while for merging with a kT cut, also the D parameter should be specified by Merging:Dparameter.

It is also possible to define the merging scale by a set of cuts imposed on the events upon generation by setting Merging:doCutBasedMerging = on. The user then has to provide the values of the three cuts: Merging:pTiMS, Merging:QijMS, and Merging:dRijMS representing the minimal transverse momentum pT_i of a single jet and the minimal invariant mass Q_ij and minimal separation ΔR_ij of every pair of jets, as used to generate the events.

Merging in Resonance Systems (Unvalidated)

The Vincia sector shower supports dedicated merging in resonance systems. At the current stage, however, this should be considered an experimental feature as it has yet to be validated. The following settings are therefore mainly intended for expert users, for instance in the context of getting started on performing such validations.

flag Vincia:MergeInResSystems (default = off)
Switch to enable merging of additional jets in resonance decay systems. Currenly handles colour-singlet resonances only.

mode Vincia:MergeNJetMaxRes (default = 0; minimum = 0)
Analogue to Merging:nJetMax, to communicate the maximum number of additional jets that can be produced from a given resonance decay system by the matrix-element generator. Only used if Vincia:MergeInResSystems = on.

mode Vincia:MergeNResSys (default = 0; minimum = 0)
The number of resonance systems allowed to produce jets if Vincia:MergeInResSystems = on and Vincia:MergeNJetMaxRes > 0.

Additionally, for simple topologies, resonances can be explicitly inserted into the event record if they have not been written to the event file by the matrix element generator. We do note that the sector merging heavily relies on this information and that attaching resonances to leptons is ambiguous for general processes.

flag Vincia:InsertResInMerging (default = off)
If set to on, Vincia tries to attach resonances to final-state leptons and insert them into the event record before constructing the shower history. If turned on, the hard process must explicitly contain a resonance, e.g. Merging:Process = { p p > Z0 }.

Treatment of QED (and other non-QCD) Corrections

Vincia's sector merging algorithm itself is so far restricted to pure QCD corrections. Thus, it is not possible to include any matrix elements with higher-order QED (or other non-QCD) corrections among the merged samples.

Vincia's QED showers can still be enabled, and will be on by default. While no fixed-order QED corrections can be included in the merging at the moment, QED showers can still be used to dress accepted events with logarithmically enhanced radiation after the merging has taken place. This means that the merging algorithm does not include QED clusterings when constructing shower histories, and QED showers are switched off during trial showers. In particular, QED branchings above the (QCD) merging scale in showers off accepted events will always be allowed, regardless of the jet multiplicity.

Vincia's electroweak showers, on the other hand, are currently not supported for merging and should not be switched on. The reason is that the emission of electroweak bosons alters the definition of the hard process, rendering the number of emissions ambiguous. An example is the process p p > j j , which may evolve to p p > j j W+ when electroweak showers are turned on. From the point of view of the QCD showers, this process may now equally well look like a Drell-Yan process p p > W+ with two QCD branchings. It is therefore only sensible to allow for electroweak showers in the merging when these are also taken into account in the construction of shower histories. As this is currently not the case, electroweak showers are not supported in the sector merging at the moment.