<chapter name="VINCIA Merging Settings"> 
 
<h2>Sector Merging (MESS) -- VINCIA only</h2> 
 
<p/> 
The VINCIA sector shower employs its own CKKW-L merging scheme, which 
differs from the one implemented for the simple showers. 
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 <bold>exactly</bold> 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. 
 
<p/> 
VINCIA's merging may be enabled by using the VINCIA sector shower and 
switching merging on: 
 
<pre> 
PartonShowers:model = 2 
Vincia:sectorShower = on 
Merging:doMerging = on 
</pre> 
 
<p/> 
In addition, the user should set 
 
<pre> 
Vincia:kineMapFFsplit = 1 
</pre> 
 
<p/> 
since the inverse kinematic map for other splitting maps are 
not currently available. We also advise running with 
 
<pre> 
Check:abortIfVeto = on 
</pre> 
 
<p/> 
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). 
 
<p/> 
We note that, different to merging with the simple showers, 
<code>Merging:doMerging</code> should always be set to <code>on</code> 
to enable merging, no matter which merging scale definition is used. 
 
<p/> 
MESS merging can generally replace CKKW-L merging with the 
simple showers and is illustrated in the command file 
<code>main162mess.cmnd</code> for <code>main162.cc</code> 
and <code>main164mess.cmnd</code> for <code>main164.cc</code>. 
However, note that a few modifications to the command file are 
needed compared to merging with the default shower, as outlined below. 
 
<h3>Matrix Elements</h3> 
 
As for merging with the simple showers, the 
user has to provide LHE files with pre-generated events with up to 
<code>N</code> additional jets. The maximal number of additional jets 
relative to the Born that do not arise from resonance decays is 
specified by setting 
 
<pre> 
Merging:nJetMax = N 
</pre> 
 
<h3>Process Specification</h3> 
 
The hard process should be specified through 
<code>Merging:Process</code>, using the following rules: 
<ul> 
<li>The whole string should be encased in curly brackets, <code>{ 
... }</code>.</li> 
<li>Specify particles one at a time, separated by whitespace, using 
Pythia's naming conventions in ParticleData.</li> 
<li>The intial and final state should be separated by 
<code>&gt;</code>.</li> 
<li>Exactly two initial state particles should be specified </li> 
<li>Resonance decays may be specifed also using <code>&gt;</code>, but 
if there is more than one particle in the intermediate final state it 
should be encased in round brackets, <code>( ... )</code>. 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.</li> 
<li> Resonances must decay to exactly 2 particles.</li> 
<li> In addition to Pythia's naming scheme, the following 
"multiparticles" are defined: 
<ul> 
<li><code>p=p+=pbar=p-=n=nbar=j={1,2,3,4,5,-1,-2,-3,-4,-5,21}</code></li> 
<li><code>q=Q=QUARK={1,2,3,4,5}</code></li> 
<li><code>qbar=QBAR=ANTIQUARK={-1,-2,-3,-4,-5}</code></li> 
<li><code>LEPTONS={11,-11,13,-13,15,-15}</code></li> 
<li><code>l+={-11,-13,-15}</code></li> 
<li><code>l-={11,13,15}</code></li> 
<li><code>NEUTRINOS={12,-12,14,-14,16,-16}</code></li> 
<li><code>nu={12,14,16}</code></li> 
<li><code>nubar={-12,-14,-16}</code></li> 
<li><code>gammaZ={22,23}</code></li> 
</ul> 
</li> 
</ul> 
We note that the option <code>Merging:Process = guess</code> 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. 
 
<h4>VBF and HEFT</h4> 
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 name="Vincia:MergeVBF" default="off"> 
Experimental switch to enable merging in VBF processes. 
</flag> 
<flag name="Vincia:MergeHEFT" default="off"> 
Experimental switch to consider HEFT couplings in the history 
construction. 
</flag> 
 
<h3>Merging Scale</h3> 
 
MESS merging presently supports three different merging scale 
definitions. If only <code>Merging:doMerging = on</code> is set, the 
shower evolution variable (a generalised <code>Ariadne</code> <ei>pT</ei>) is 
used to define the merging scale. Additionally, the merging scale may be 
defined in terms of a <ei>kT</ei> cut by setting 
 
<pre> 
<code>Merging:doKTMerging = on</code> 
</pre> 
 
<p/> 
and (optionally) specifying <code>Merging:ktType</code>, see 
<aloc href="CKKWLMerging">CKKW-L Merging</aloc> for details.  In both cases, 
the merging scale should be specified through <code>Merging:TMS</code> 
while for merging with a <ei>kT</ei> cut, also the <ei>D</ei> 
parameter should be specified by <code>Merging:Dparameter</code>. 
 
<p/> 
It is also possible to define the merging scale by a set of cuts 
imposed on the events upon generation by setting 
<code>Merging:doCutBasedMerging = on</code>. The user then has to 
provide the values of the three cuts: <code>Merging:pTiMS</code>, 
<code>Merging:QijMS</code>, and <code>Merging:dRijMS</code> 
representing the minimal transverse momentum <ei>pT<sub>i</sub></ei> 
of a single jet and the minimal invariant mass <ei>Q<sub>ij</sub></ei> 
and minimal separation <ei>&Delta;R<sub>ij</sub></ei> of every pair of 
jets, as used to generate the events. 
 
<h3>Merging in Resonance Systems (Unvalidated)</h3> 
 
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 name="Vincia:MergeInResSystems" default="off"> 
Switch to enable merging of additional jets in resonance 
decay systems. Currenly handles colour-singlet resonances only. 
</flag> 
 
<mode name="Vincia:MergeNJetMaxRes" default="0"  min="0"> 
Analogue to <code>Merging:nJetMax</code>, 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 
<code>Vincia:MergeInResSystems = on</code>. 
</mode> 
 
<mode name="Vincia:MergeNResSys" default="0"  min="0"> 
The number of resonance systems allowed to produce jets if 
<code>Vincia:MergeInResSystems = on</code> and 
<code>Vincia:MergeNJetMaxRes > 0</code>. 
</mode> 
 
<p/> 
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 name="Vincia:InsertResInMerging" default="off"> 
If set to <code>on</code>, 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. <code>Merging:Process = { p p > 
Z0 }</code>. 
</flag> 
 
<h3>Treatment of QED (and other non-QCD) Corrections</h3> 
 
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. 
<p/> 
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. 
 
<p/> 
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 <code>p p > j j </code>, which may evolve 
to <code>p p > j j W+</code> 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 <code>p p > W+ </code> 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. 
 
</chapter> 
 
<!-- Copyright (C) 2025 Torbjorn Sjostrand --> 
