/usr/share/doc/pythia8-doc/html/UMEPSMerging.html is in pythia8-doc-html 8.1.86-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 |
<html>
<head>
<title>UMEPS Merging</title>
<link rel="stylesheet" type="text/css" href="pythia.css"/>
<link rel="shortcut icon" href="pythia32.gif"/>
</head>
<body>
<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 [<a href="Bibliography.html" target="page">Lon12</a>]. 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 [<a href="Bibliography.html" target="page">Lon12</a>]. 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 sample main program
<code>main86.cc</code>, together with the input file
<code>main86.cmnd</code>.
<p/>
Unitarised merging is heavily indebted to CKKW-L merging, and shares many
settings with CKKW-L. In particular,
<p/>
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
<a href="CKKWLMerging.html" target="page">CKKW-L documentation</a>).
<p/>
The merging scale value
(<code>Merging:TMS</code>) has to be set.
<p/>
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 <a href="CKKWLMerging.html" target="page">CKKW-L
documentation</a> 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 main86.cc</h3>
The UMEPS procedure is illustrated in the sample main program
<code>main86.cc</code> (with the input card <code>main86.cmnd</code>). This
program produces HepMC events [<a href="Bibliography.html" target="page">Dob01</a>], that can be histogrammed (e.g.
using RIVET [<a href="Bibliography.html" target="page">Buc10</a>]), 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
<i>histPTFirstSum</i> in <code>main84.cc</code>, i.e. using
<i>weight*normhepmc</i> as weight.
<p/>
In principle, no changes to <code>main86.cc</code> are necessary. Instead, all
settings can be transferred to <code>main86.cc</code> through an input file.
The input LHE files are also part of the (command line) input of
<code>main86.cc</code>. Note that the sample program assumes that LHE file
names are of the form <i>name_tree_#nAdditionalJets.lhe</i>. If you want to
e.g. use the LHE files that are shipped with the Pythia distribution, you can
execute <code>main86.exe</code> with the command
</p>
<code>./main86.exe ./main86.cmnd ./w_production ./myhepmc.hepmc</code>
</p>
Since <code>main86.cc</code> is currently the "front-end" for UMEPS merging,
we will briefly discuss this sample program in the following.
<h4>Inputs</h4>
In its current form, <code>main86.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 <i>pT<sub>jet</sub> = 5 GeV</i>,
<i> ΔR<sub>jetA jetB</sub> = 0.01</i> and
<i> Q<sub>jetA jetB</sub> = 5 GeV</i>.
<p/>
All input settings are handed to <code>main86.cc</code> in the form of an
input file. This input file has to contain
<p/>
The number of desired events
(<code>Main:numberOfEvents</code>)
<p/>
The hard process
(<code>Merging:Process</code>)
<p/>
The merging scale value
(<code>Merging:TMS</code>)
<p/>
The maximal number of additional partons
(<code>Merging:nJetMax</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 hadronisation 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.
<p/><code>flag </code><strong> Merging:doUMEPSTree </strong>
(<code>default = <strong>off</strong></code>)<br/>
Reweight events according to the UMEPS prescription for tree-level
configurations.
<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.
<code>main86.cc</code> makes this cancellation explicit by producing
(correctly weighted) counter events by switching on
<p/><code>flag </code><strong> Merging:doUMEPSSubt </strong>
(<code>default = <strong>off</strong></code>)<br/>
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.
<p/> The integration is achieved internally, and the number of desired
integrations (which is always one for UMEPS counter events) is set by
<p/><code>mode </code><strong> Merging:nRecluster </strong>
(<code>default = <strong>0</strong></code>; <code>minimum = 0</code>)<br/>
Number of hard partons to integrate out in the UMEPS procedure.
<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 <i>-1</i>, should then be used as event weight (or to fill
histogram bins).
<p/>
Before returning, <code>main86.cc</code> prints the merged cross section
after UMEPS merging.
</body>
</html>
<!-- Copyright (C) 2014 Torbjorn Sjostrand -->
|