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 command file
main162mess.cmnd
for main162.cc
and main164mess.cmnd
for main164.cc
.
However, note that a few modifications to the command file are
needed compared to merging with the default shower, 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 pTi
of a single jet and the minimal invariant mass Qij
and minimal separation ΔRij 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.