 
<chapter name="UMEPS Merging"> 
 
<h2>Unitarised Matrix Element + Parton Shower Merging</h2> 
 
Pythia offers the possibility to use the unitarised matrix element + parton 
shower merging scheme, as presented in <ref>Lon12</ref>. Unitarised ME+PS 
merging (UMEPS) allows for a consistent inclusion of tree-level multi-parton 
matrix elements into Pythia, and prevents potential changes in the inclusive 
production cross section. This makes it theoretically more appealing than 
CKKW-L merging. As in CKKW-L, UMEPS merging requires the user to supply Les 
Houches Event File input. 
 
<p/> 
UMEPS is different from other tree-level merging schemes in that it contains 
events with negative weights. These are generated by constructing 
parts of no-emission probabilities by reweighted higher-multiplicity 
samples <ref>Lon12</ref>. The main philosophy of UMEPS is "subtract what you 
add", meaning that in order to ensure the stability of the inclusive cross 
section, one has to counter the inclusion of additional tree-level matrix 
elements by "subtraction terms". 
 
<p/> The scheme closely reflects how unitarity 
is achieved in a non-merged shower, and indeed explicitly enforces the 
cancellations that are implicitly happening in a non-merged shower. This makes 
very low merging scale values possible. 
 
<p/> 
The usage of UMEPS is illustrated in the input file 
<code>main162umeps.cmnd</code> for <code>main162.cc</code>. 
 
<p/> 
Unitarised merging is heavily indebted to CKKW-L merging, and shares many 
settings with CKKW-L. In particular, 
<p/> 
 &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The hard process 
(<code>Merging:Process</code>)needs to be defined 
exactly as in CKKW-L (see <strong>Defining the hard process</strong> in the 
<aloc href="CKKWLMerging">CKKW-L documentation</aloc>). 
<p/> 
 &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The merging scale value 
(<code>Merging:TMS</code>) has to be set. 
<p/> 
 &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The maximal number of additional partons 
<code>Merging:nJetMax</code> has to be set. 
 
<p/> 
UMEPS further shares the switches listed under the sections "<strong>Matrix 
element merging and HepMC output for RIVET</strong>" and "<strong>Further 
variables</strong>" in  the <aloc href="CKKWLMerging">CKKW-L 
documentation</aloc> with CKKW-L merging. Also, all 
<code>MergingHooks</code> routines that allow for user interference in 
CKKW-L merging are also usable for UMEPS -- with the exception of a 
user-defined merging scale. 
Currently, UMEPS is only implemented for a merging scale defined 
by the minimal Pythia evolution pT value between sets of radiator, emitted 
and recoiler partons. This is no fundamental limitation of the method, and 
will possibly be lifted in the future. Since this merging scale definition is 
not completely obvious, UMEPS also shares the 
<code>Merging:enforceCutOnLHE</code> switch with CKKW-L. In this way, it 
is possible to use LHE files that are regularised only with weak cuts as 
input, while the merging machinery imposes the stronger merging scale cut 
automatically. This means that no merging scale implementation is required 
from the user side, but also means that it is the user's responsibility to 
ensure that the cuts used for generating input LHE files are always looser 
than the cut given by the merging scale value <code>Merging:TMS</code>. 
 
<br/><br/><hr/> 
<h3>UMEPS merging with main162.cc</h3> 
 
The UMEPS procedure is illustrated in the input card 
<code>main162umeps.cmnd</code> for <code>main162.cc</code>. This 
program produces HepMC events <ref>Dob01</ref>, that can be histogrammed (e.g. 
using RIVET <ref>Buc10</ref>), or used as input for a detector simulation. If 
the user is not familiar with HepMC analysis tools, it is possible to instead 
use Pythia's histogramming routines. For this, remove the lines referring to 
HepMC, and histogram events as illustrated (for CKKW-L) for the histogram 
<ei>histPTW</ei> in <code>main161.cc</code>, i.e. using 
<ei>weight*norm</ei> as weight. 
 
<p/> 
In principle, no changes to <code>main162.cc</code> are necessary. Instead, 
all settings can be transferred to <code>main162.cc</code> through an input 
file. The input LHE files are part of the command file 
<code>main162umeps.cmnd</code>. 
 
<h4>Inputs</h4> 
 
In its current form, <code>main162.cc</code> uses separate tree-level 
LHE files for different numbers of additional partons as input. If 
e.g. UMEPS merging for W-boson + up to two additional partons is to be 
performed, three LHE files (for W+zero, W+one, W+two partons) are 
required. The configurations in the input files should be regularised 
with inclusive (i.e. weak) cuts. The actual "merging scale cut" will 
be handled internally. If e.g. <code>Merging:TMS = 15</code> is the 
desired merging scale value, it is acceptable to regularise the matrix 
element calculation for Higgs+jets events at the LHC with the loose 
cuts <ei>pT<sub>jet</sub> = 5 GeV</ei>, 
<ei> &Delta;R<sub>jetA jetB</sub> = 0.01</ei> and 
<ei> Q<sub>jetA jetB</sub> = 5 GeV</ei>. 
 
<p/> 
All input settings are handed to <code>main162.cc</code> in the form of an 
input file. This input file has to contain 
<p/> 
 &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The number of desired events 
(<code>Main:numberOfEvents</code>) 
<p/> 
 &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The hard process 
(<code>Merging:Process</code>) 
<p/> 
 &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The merging scale value 
(<code>Merging:TMS</code>) 
<p/> 
 &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The maximal number of additional partons 
(<code>Merging:nJetMax</code>). 
&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; The number of subruns (for UMEPS 
<ei>2*<code>nJetMax</code>-1</ei> are needed) 
&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; One subrun for each multiplicity and 
treatment, starting with <code>Main:subrun = &lt;nSubrun&gt;</code> 
<p/> 
Other settings are of course allowed. However, please refrain from adding 
switches that are used to invoke other merging schemes (e.g. 
<code>Merging:doKTMerging</code>) into the input file, since this can 
cause problems. 
 
<h4>Program flow</h4> 
 
The sample program starts by estimating the cross section for samples with 
different jet multiplicities. For this, the switch 
<code>Merging:doXSectionEstimate</code> is invoked together with the merging 
scale definition of <code>Merging:doUMEPSTree</code>, which corresponds to the 
minimal Pythia evolution pT value. We will come back to the latter switch 
below. All showering, multiparton interactions and hadronization is, for speed 
reasons, switched off when estimating the cross section, since the hard cross 
section estimate would not be influenced by the event evolution anyway. 
 
<p/> 
After the hard cross sections are known (including the application of the 
merging scale cut), the first part of the UMEPS events is generated by 
using the following switch. 
 
<flag name="Merging:doUMEPSTree" default="off"> 
Reweight events according to the UMEPS prescription for tree-level 
configurations. 
</flag> 
 
<p/> 
The weight generated by the UMEPS procedure can be accessed by using the 
function <strong> double Info::mergingWeight()</strong>. 
When printing (or histogramming) merged events, this weight, multiplied 
with the estimated cross section for the current sample, should be 
used as event weight (or to fill histogram bins). 
 
<p/> 
After this first part is complete, the outcome is an addition of reweighted 
tree-level samples. To restore the inclusive cross section (i.e. that the 
cross section after merging corresponds to the cross section of the hard 
process, without any additional jets), it is necessary to subtract samples. 
Parton shower unitarity leads to the conclusion that "resolved" and 
"unresolved" corrections always cancel between states that contain an 
additional resolved jet, and states in which we "integrate over" the phase 
space of the additional jet. 
UMEPS makes this cancellation explicit by producing 
(correctly weighted) counter events by switching on 
 
<flag name="Merging:doUMEPSSubt" default="off"> 
Reweight events according to the UMEPS prescription of reweighted, 
integrated configurations. Please note that, in order for this to work 
smoothly, the switch <code>Merging:doUMEPSTree</code> has to be turned off. 
</flag> 
 
<p/> The integration is achieved internally, and the number of desired 
integrations (which is always one for UMEPS counter events) is set by 
 
<modeopen name="Merging:nRecluster" default="0" min="0"> 
Number of hard partons to integrate out in the UMEPS procedure. 
</modeopen> 
 
<p/> Again, the weight generated by the UMEPS procedure can be accessed by 
using the function <strong> double Info::mergingWeight()</strong>. This 
weight, multiplied with the cross section of the current sample, and 
multiplied by <ei>-1</ei>, should then be used as event weight (or to fill 
histogram bins). 
 
<p/> 
Finally, <code>main162.cc</code> prints the merged cross section 
after UMEPS merging. 
 
 
</chapter> 
 
<!-- Copyright (C) 2026 Torbjorn Sjostrand --> 
