2 <chapter name="NLO Merging">
6 Pythia offers two NLO merging approaches. Both of these methods have been
7 presented in <ref>Lon13</ref>. The goal of NLO merging is to extend tree-level
8 multi-jet merging methods to next-to-leading order accuracy in QCD, for every
9 available jet multiplicity. If for example NLO calculations for Higgs + 0 jet,
10 Higgs + 1 jet and Higgs + 2 jets were available, NLO merging allows to
11 simultaneously describe 0-, 1- and 2-jet observables with NLO accuracy.
12 Further jets can, depending on additional tree-level input, be described by
13 additional tree-level matrix elements. In the example, it would be possible to
14 achieve NLO accuracy for 0-, 1- and 2-jet observables, tree-level accuracy
15 for 3-, 4- and 5-jet configurations, and use the parton shower approximation
16 for events with more than five jets.
18 <p/> The two NLO merging methods implemented in Pythia are called
19 NL<sup>3</sup> (for Nils Lavesson + Leif Lönnblad) and UNLOPS
21 NLO+PS merging). Both of these schemes require Les Houches Event File input
22 that is generated by tree-level or NLO matrix element generators. Currently,
23 Pythia requires NLO input generated within the POWHEG framework. The
24 generation of sensible input will be discussed below. The two NLO merging
25 methods are illustrated in the sample main programs <code>main87.cc</code>
26 (introducing NL<sup>3</sup> ) and <code>main88.cc</code> (introducing UNLOPS).
27 Before describing these programs, we would like to outline the differences
28 between the two approaches.
30 <p/> NL<sup>3</sup> is a generalisation of <aloc href="CKKWLMerging">CKKW-L
31 tree-level merging</aloc>. The main
32 idea of NL<sup>3</sup> is to start from CKKW-L-reweighted multi-jet
33 merging, and replace the
34 <ei>α<sub>s</sub><sup>n+0</sup></ei>- and
35 <ei>α<sub>s</sub><sup>n+1</sup></ei>-terms by the NLO result of POWHEG.
36 This "replacement" means that we subtract the
37 <ei>α<sub>s</sub><sup>n+0</sup></ei>- and
38 <ei>α<sub>s</sub><sup>n+1</sup></ei>-terms from the CKKW-L-reweighted
39 tree-level samples, and add another sample -- the POWHEG input.
40 All "higher orders" are unchanged w.r.t. CKKW-L.
41 We have implemented the
42 "inclusive" scheme of <ref>Lon13</ref> in Pythia. This means that the POWHEG
43 input will contain contributions for hard, resolved real emission jets, which
44 are already taken care of by higher-multiplicity samples in CKKW-L. Thus,
45 explicit phase space subtractions are also included. The sample program
46 <code>main87.cc</code>, together with the input file <code>main87.cmnd</code>,
47 illustrates the procedure.
49 <p/> UNLOPS is a generalisation of the
50 <aloc href="UMEPSMerging">UMEPS multi-jet merging</aloc> scheme.
51 Since UMEPS is already slightly more complicated than
52 CKKW-L, this makes UNLOPS more complicated than NL<sup>3</sup>. The basic idea
53 however remains the same: Start from a tree-level merging scheme (in this case
54 UMEPS), remove all undesirable <ei>α<sub>s</sub><sup>n+0</sup></ei>- and
55 <ei>α<sub>s</sub><sup>n+1</sup></ei>-terms from this result, and add back
56 the "correct" description via POWHEG input samples. Again, since the
57 "inclusive" scheme of <ref>Lon13</ref> was implemented in Pythia, it is
58 necessary to handle explicit phase space subtractions. Similar to
59 UMEPS, UNLOPS further ensures that the lowest-multiplicity cross section
60 is given by the NLO result. This means that the UMEPS philosophy of "subtract
61 what you add" needs to be extended to multi-leg NLO inputs.
63 <p/> UNLOPS is a theoretically more appealing definition of NLO merging than
64 NL<sup>3</sup>, and should thus be considered the preferred choice. However,
65 we believe it valuable to include both methods into Pythia, so that the
66 variation of NLO merged results due to different NLO merging schemes can be
67 studied in situ. Furthermore, NLO merging can be outlined more pedagogically
68 when starting from NL<sup>3</sup>. The two NLO merging methods share parts of
69 code with CKKW-L and UMEPS, and correspondingly share many input settings
70 with these schemes. In particular,
72 The hard process
73 (<code>Merging:Process</code>) needs to be defined
74 exactly as in CKKW-L (see <strong>Defining the hard process</strong> in the
75 <aloc href="CKKWLMerging">CKKW-L documentation</aloc>).
77 The merging scale value
78 (<code>Merging:TMS</code>) has to be set.
80 The maximal number of additional partons in
81 tree-level events (<code>Merging:nJetMax</code>) has to be set.
83 <p/> All settings listed under the sections "<strong>Matrix element
84 merging and HepMC output for RIVET</strong>" and "<strong>Further
85 variables</strong>" in the <aloc href="CKKWLMerging">CKKW-L
86 documentation</aloc> can be accessed in NLO merging as well. Furthermore,
87 the <code>Merging:nRecluster</code> switch (see the
88 <aloc href="UMEPSMerging">UMEPS documentation</aloc>) is important.
90 Also, all <code>MergingHooks</code> routines that allow for user
91 interference in CKKW-L merging are also usable for NLO merging -- with the
92 exception of a user-defined merging scale. The NLO merging schemes currently
93 implemented in Pythia do not allow for a merging scale definition that
94 differs from the parton shower evolution variable. Since this merging scale
95 definition is not completely obvious, the NLO merging schemes also share the
96 <code>Merging:enforceCutOnLHE</code> switch with CKKW-L. In this way, it
97 is possible to use LHE files that are regularised only with weak cuts as
98 input, while the merging machinery imposes the stronger merging scale cut
99 automatically. This means that no merging scale implementation is required
100 from the user side, but also means that it is the user's responsibility to
101 ensure that the cuts used for generating input LHE files are always looser
102 than the cut given by the merging scale value <code>Merging:TMS</code>. This
103 will lead to warnings of the form "<code>Les Houches Event fails merging scale
104 cut. Cut by rejecting event</code>". These warning should rather be regarded as
105 information. An example of inclusive matrix element generation cuts would be
106 <ei>pT<sub>jet</sub> = 5 GeV</ei>, <ei>ΔR<sub>jetA jetB</sub> =
107 0.01</ei> and <ei>Q<sub>jetA jetB</sub> = 5 GeV</ei>, if NLO merging with a
108 desired merging scale value of <code>Merging:TMS = 15</code> is attempted for
109 Higgs + jets events at the LHC.
111 <p/> In the following, we will first describe the generation of NLO input
112 samples, and list input settings for NLO merging in Pythia. Then, we will
113 examine the sample main programs <code>main87.cc</code> and
114 <code>main88.cc</code>, which implement NL<sup>3</sup> and UNLOPS merging,
118 <h3>Inputs for NLO merging</h3>
120 The NLO merging schemes in Pythia currently require Les Houches Event File
121 input. To perform a merging with up to <ei>M</ei> additional partons described
122 by tree-level matrix elements, and with up to <ei>N ≤ M-1</ei> additional
123 partons at NLO accuracy, the user needs to supply
125 LHE files for <ei>0... M</ei> additional
126 partons, taken from a tree-level matrix element generator, and
128 LHE files for <ei>0... N</ei> additional
129 partons, taken from a POWHEG NLO generator.
130 <p/> All input files need to be regularised, if they contain additional
131 partons. Large files with fairly inclusive (i.e. loose) cuts are recommended.
132 The input LHE files should further be generated with fixed renormalisation
133 and factorisation scales. (In the POWHEG-BOX program, this means using the
134 settings <code>runningscales 0, btlscalereal 1, btlscalect 1,
135 ckkwscalup 0</code>. Some older processes in the POWHEG-BOX program need the
136 input <code>runningscale 0</code> instead of <code>runningscales 0</code>.)
138 <p/> When attempting NLO merging, the following Pythia settings are relevant.
140 <modeopen name="Merging:nJetMaxNLO" default="0" min="0">
141 The maximal number of additional jets for which NLO event samples are
142 supplied by the user.
145 <parm name="Merging:muFac" default="-1.0">
146 The fixed factorisation scale used in the hard process cross section,
148 generate the leading-order weight, in case the factorisation scale cannot
149 be inferred from Les Houches event input. (This is the case for files that
150 have been generated with the POWHEG-BOX program, since this program prints
151 the transverse momentum scale of the real emission into the LH events.).
152 If the value is not set, the <code>SCALUP</code> variable of the current LH
153 event will be used instead.
156 <parm name="Merging:muRen" default="-1.0">
157 The fixed renormalisation scale used in the hard process cross section,
159 generate the leading-order weight, in case the renormalisation scale cannot
160 be inferred from Les Houches event input. (As mentioned above, this is the
161 case for files generated with the POWHEG-BOX program.)
162 If the value is not set, the <code>SCALUP</code> variable of the current LH
163 event will be used instead.
166 <parm name="Merging:muFacInME" default="-1.0">
167 The fixed factorisation scale used in the matrix element calculation. This
168 information is needed if factorisation scale variations in NLO merged results
169 are attempted. Depending on the matrix element generator, it might not be
170 possible to infer the factorisation scale from Les Houches event input, and
171 thus, setting an explicit value is required. (As mentioned above, this is the
172 case for files generated with the POWHEG-BOX program.)
173 If the value is not set, the <code>SCALUP</code> variable of the current LH
174 event will be used instead.
177 <parm name="Merging:muRenInME" default="-1.0">
178 The fixed renormalisation scale used in the matrix element calculation. This
179 information is needed if renormalisation scale variations in NLO merged
180 results are attempted, for the same reason as factorisation scales might be
181 required. (As mentioned above, this is the case for files generated with the
183 If the value is not set, the <code>SCALUP</code> variable of the current LH
184 event will be used instead.
187 <p/> All further settings will be discussed while examining the sample main
191 <h3>NL<sup>3</sup> merging with main87.cc</h3>
193 NL<sup>3</sup>-style NLO merging in Pythia is illustrated by the sample
194 main program <code>main87.cc</code>. This program works together with an input
195 file (e.g. <code>main87.cmnd</code>) for Pythia settings, and requires LHE
196 input files that follow the naming convention
197 <ei>name_tree_#nAdditionalJets.lhe</ei> (tree-level samples) and
198 <ei>name_powheg_#nAdditionalJets.lhe</ei> (POWHEG NLO samples).
199 <code>main87.cc</code> produces HepMC event output <ref>Dob01</ref>, which can
200 be used for analysis (e.g. using RIVET <ref>Buc10</ref>), or as input for
201 detector simulations. For users not familiar with HepMC output, it is of
202 course possible remove the HepMC code in the sample program, and use Pythia's
203 histogramming routines instead. Histograms should then be filled as indicated
204 for the <ei>histPTFirstSum</ei> histograms in <code>main84.cc</code>, i.e.
205 using <ei>weightNLO*normhepmc</ei>.
207 <p/> If the user only wants to change the number of requested events
208 (<code>Main:numberOfEvents</code>), the hard process
209 (<code>Merging:Process</code>), the merging scale value
210 (<code>Merging:TMS</code>) and the maximal number of additional tree-level or
211 NLO-accuracte jets (<code>Merging:nJetMax</code> and
212 <code>Merging:nJetMaxNLO</code>, respectively), and HepMC output is desired,
213 then there is no need to change the <code>main87.cc</code> code. The input
214 LHE files are also part of the (command line) input for <code>main87.exe</code>.
215 The default settings in <code>main87.cmnd</code> are intended to work with the
216 (very short) sample LHEF inputs (<ei>w_production_tree_0.lhe</ei>,
217 <ei>w_production_tree_1.lhe</ei>, <ei>w_production_tree_2.lhe</ei> and
218 <ei>w_production_powheg_0.lhe</ei>, <ei>w_production_powheg_1.lhe</ei>). For
219 these input files, the <code>main87.exe</code> executable can be run with
222 <code>./main87.exe main87.cmnd w_production myhepmc.hepmc</code>
223 <p/> to produce a file myhepmc.hepmc of NLO merged HepMC event output. All
224 mandatory Pythia input settngs have been outlined earlier. Please refrain from
225 adding input switches than invoke any other merging scheme (e.g. e.g.
226 <code>Merging:doKTMerging</code>) into the input file that you want to use in
227 conjunction with <code>main87.cc</code>.
229 <p/> In the following, we will explain <code>main87.cc</code> in depth. Users
230 who are willing to accept the default choices do not need to know all details,
231 but are still encouraged to read further.
233 <h4>Program flow</h4>
235 <code>main87.cc</code> can be divided into four steps:
236 <p/> 1. Estimate the cross section for
237 tree-level and NLO samples <ei>after</ei> the merging scale cut.
238 <p/> 2. Produce reweighted tree-level events,
239 which do not contain <ei>α<sub>s</sub><sup>0</sup></ei>- and
240 <ei>α<sub>s</sub><sup>1</sup></ei>-terms.
241 <p/> 3. Add POWHEG NLO events.
242 <p/> 4. Subtract phase space points with an
243 extra (real-emission) jet above the merging scale from the POWHEG result,
244 since such configurations have already been taken into account by
245 processing other samples.
247 <p/> The first step is necessary to produce the correct weights for HepMC
248 output events. The estimation of tree-level cross sections after the merging
249 scale cut is generated by invoking the switch
250 <code>Merging:doXSectionEstimate</code> together with
251 <code>Merging:doNL3Tree</code>. In this configuration, the latter switch will
252 only act to define the merging scale. After the tree-level cross sections
253 have been estimated, <code>main87.cc</code> estimates the NLO cross sections
254 after application of the merging scale cut, by inferring
255 <code>Merging:doXSectionEstimate</code> together with
256 <code>Merging:doNL3Loop</code>. Again, in this configuration, the latter
257 switch only acts as the merging scale definition. When generating the
258 estimates, all showering, multiparton interactions and hadronisation is
259 turned off to not unnecessarily waste processor time.
260 For all estimates, is further <ei>mandatory</ei> to set the value of
261 <code>Merging:nRequested</code> to the jet multiplicity of the current event
262 sample (e.g. to "2" for a sample containing W + 2 jet events). This is
263 necessary in order to correctly apply the merging scale cut. POWHEG
264 NLO input files for W + 1 jet e.g. contain W + 1 jet and W + 2 jet (i.e. real
265 emission) kinematics. However, the merging scale cut aims at
266 regularising the "underlying Born" configuration (i.e. the W + 1 states in our
267 example). Setting <code>Merging:nRequested = 1</code> for the W + 1 jet
268 POWHEG sample ensures that even for real-emission (W + 2 jet) kinematics, the
269 merging scale cut is applied to W + 1 jet states.
271 <p/> After the cross section estimation step, <code>main87.cc</code> proceeds
272 to perform the actual merging. Before explaining this part, we would like to
273 make some comments about K-factors.
275 <p/> <code>main87.cc</code> is prepared to use
276 fixed K-factors to rescale the weight of tree-level events. This rescaling
277 does not affect the NLO accuracy of the method, and was investigated in
278 <ref>Lon13</ref>. By default, <code>main87.cc</code> does not use K-factors.
279 However, if the user wants to include K-factors, this can be done by using
280 the following input settings.
282 <parm name="Merging:kFactor0j" default="1.0">
283 The k-Factor used to rescale the tree-level (i.e. CKKW-L or UMEPS) part of
284 zero-jet tree-level events.
287 <parm name="Merging:kFactor1j" default="1.0">
288 The k-Factor used to rescale the tree-level (i.e. CKKW-L or UMEPS) part of
289 one-jet tree-level events.
292 <parm name="Merging:kFactor2j" default="1.0">
293 The k-Factor used to rescale the tree-level (i.e. CKKW-L or UMEPS) part of
294 two-jet tree-level events.
297 <p/> If the variables <ei>k0, k1, k2</ei> in <code>main87.cc</code> are set
298 to non-unity values, K-factors will be applied. The K-factor
299 of highest jet multiplicity will then be used
300 to also rescale tree-level samples with a number of additional jets
301 beyond the number of the highest-multiplicity real-emission sample. If we, for
302 example, attempt an NLO merging of <ei>W+0 jet</ei> and <ei>W+1 jet</ei> at NLO
303 accuracy, and with <ei>W+≤4 jets</ei> at tree-level accuracy, then
304 <code>Merging:kFactor2j</code> is used to rescale the <ei>W+2 jet</ei>,
305 <ei>W+3 jets</ei> and <ei>W+4 jets</ei> tree-level samples. We recommend to
306 not include a K-factor rescaling of the tree-level samples.
309 <p/> Let us turn to the production of NLO merged events. The first step in
310 the procedure is to generate reweighted tree-level samples. This is
311 implemented by using the following switch.
313 <flag name="Merging:doNL3Tree" default="off">
314 This switch will allow the generation of the weight that should be applied to
315 tree-level events in the NL<sup>3</sup> merging scheme. Please note that, in
316 order for this to work smoothly, the switch <code>Merging:doNL3Loop</code> and
317 the switch <code>Merging:doNL3Subt</code> have to be turned off. As for the
318 estimation of cross sections, it is <ei>mandatory</ei> to set
319 the correct value of <code>Merging:nRequested</code>.
323 The weight of tree-level events can be accessed by calling the function
324 <strong>double Info::mergingWeightNLO()</strong>. When printing
325 (or histogramming) NLO merged events, this weight, multiplied with the
326 estimated cross section of the current event sample, should be used as event
327 weight (or weight of histogram bins). For <code>Merging:doNL3Tree = on</code>,
328 the weight <strong>double Info::mergingWeightNLO()</strong> contains the
329 CKKW-L weight, subtracted, if necessary, by
330 <ei>α<sub>s</sub><sup>0</sup></ei>- and
331 <ei>α<sub>s</sub><sup>1</sup></ei>-terms. This weight can become
332 negative. As an example, imagine we attempt an NLO merging of W + 0 jet and
333 W + 1 jet at NLO accuracy, and with W + 2 jets at tree-level accuracy.
334 This weight will then be
335 <p/> <ei>Info::mergingWeightNLO() = CKKW-L-weight for zero jets
336 - <ei>α<sub>s</sub><sup>0</sup></ei>-terms
337 - <ei>α<sub>s</sub><sup>1</sup></ei>-terms
338 </ei> for events in the zero-jet sample,
339 <p/> <ei>Info::mergingWeightNLO() = CKKW-L-weight for one jet
340 - <ei>α<sub>s</sub><sup>0</sup></ei>-terms
341 - <ei>α<sub>s</sub><sup>1</sup></ei>-terms
342 </ei> for events in the one-jet sample, and
343 <p/> <ei>Info::mergingWeightNLO() = CKKW-L-weight for two jets </ei>
344 for events in the two-jet sample.
346 <p/> After the tree-level events have been reweighted, <code>main87.cc</code>
347 will move on to process the POWHEG NLO input. This is done by switching to the
350 <flag name="Merging:doNL3Loop" default="off">
351 This switch will allow the processing of POWHEG NLO events in the
352 NL<sup>3</sup> merging scheme. Please note that, in order for this to work
353 smoothly, the switch <code>Merging:doNL3Tree</code> and the switch
354 <code>Merging:doNL3Subt</code> have to be turned off. As for the estimation
355 of cross sections, it is <ei>mandatory</ei> to set the correct value of
356 <code>Merging:nRequested</code>.
360 Also in this case, the NLO merging weight of the events can be accessed by
361 calling the function <strong>double Info::mergingWeightNLO()</strong>. This
362 weight should also be used when printing (or histogramming) events.
363 For <code>Merging:doNL3Loop = on</code>,
364 the weight <strong>double Info::mergingWeightNLO()</strong> is either one or
365 zero (see Appendix E in <ref>Lon13</ref>).
367 After the processing of POWHEG NLO events, <code>main87.cc</code> continues
368 by generating explicit phase space subtractions. This is facilitated by the
371 <flag name="Merging:doNL3Subt" default="off">
372 This switch will allow the processing of tree-level events, to produce explicit
373 phase space subtractions in the NL<sup>3</sup> merging scheme. Please note
374 that, in order for this to work smoothly, the switch
375 <code>Merging:doNL3Tree</code> and the switch
376 <code>Merging:doNL3Loop</code> have to be turned off. As for the estimation
377 of cross sections, it is <ei>mandatory</ei> to set the correct value of
378 <code>Merging:nRequested</code>. Furthermore, it is necessary to set the
379 value of <code>Merging:nRecluster</code> to one.
382 <p/> These contributions are necessary because we have implemented
384 scheme" of <ref>Lon13</ref> in Pythia. The benefit of this scheme is the user
385 does not have to intrusively change the POWHEG-BOX program to implement very
386 particular cuts. Let us explain this comment with an example (a more detailed
387 explanation of the idea is given in Appendix A.2 of <ref>Lon13</ref>). When
388 generating W + 0 jet events with the POWHEG-BOX program, the output LHE files
389 will contain W + 1 jet real emission events. Some of these events will
390 contain a jet above the merging scale. However, in NLO merging methods, such
391 configurations have already been included by a separate W + 1 jet sample. Thus,
392 to avoid counting such events twice, we have to remove the configurations from
393 the POWHEG-BOX output. We choose to remove such events by explicit
397 As always, the NLO merging weight of the events can be accessed by
398 calling the function <strong>double Info::mergingWeightNLO()</strong>. This
399 weight should also be used when printing (or histogramming) events.
400 For <code>Merging:doNL3Subt = on</code>,
401 the weight <strong>double Info::mergingWeightNLO()</strong> is either one or
402 zero (see Appendix E in <ref>Lon13</ref>).
404 <p/> After these steps, all necessary events for NL<sup>3</sup> merging have
405 been produced. <code>main87.cc</code> finishes by returning the
406 NL<sup>3</sup>-merged total cross section.
410 <h3>UNLOPS merging with main88.cc</h3>
412 UNLOPS-style NLO merging in Pythia is illustrated by the sample
413 main program <code>main88.cc</code>, which relies on an input file (e.g.
414 <code>main88.cmnd</code>) for Pythia settings. As for all merging methods in
415 Pythia, <code>main88.cc</code> requires LHE input files. To use
416 <code>main88.cc</code> without any changes, these input files should follow
417 the naming convention <ei>name_tree_#nAdditionalJets.lhe</ei> (for tree-level
418 samples) and <ei>name_powheg_#nAdditionalJets.lhe</ei> (for POWHEG NLO
419 samples). <code>main88.cc</code> produces HepMC event output, which can e.g.
420 be analysed with RIVET, or used as input for detector simulations.
421 For users not familiar with HepMC output, it is of course possible remove
422 the HepMC code in the sample program, and use Pythia's histogramming routines
423 instead. Histograms should then be filled as indicated for the
424 <ei>histPTFirstSum</ei> histograms in <code>main84.cc</code>, i.e. using
425 <ei>weightNLO*normhepmc</ei>.
427 <p/> As for NL<sup>3</sup>, it is not necessary to change
428 <code>main88.cc</code> if the user is only interested in changing standard
429 settings. Thus, if the user only wants to change the number of requested
430 events (<code>Main:numberOfEvents</code>), the hard process
431 (<code>Merging:Process</code>), the merging scale value
432 (<code>Merging:TMS</code>) and the maximal number of additional tree-level or
433 NLO-accuracte jets (<code>Merging:nJetMax</code> and
434 <code>Merging:nJetMaxNLO</code>, respectively), and HepMC output is desired,
435 then there is no need to change the <code>main88.cc</code> code. The input
436 LHE files are also part of the (command line) input for <code>main88.exe</code>.
437 The default settings in <code>main88.cmnd</code> are intended to work with the
438 (very short) sample LHEF inputs (<ei>w_production_tree_0.lhe</ei>,
439 <ei>w_production_tree_1.lhe</ei>, <ei>w_production_tree_2.lhe</ei> and
440 <ei>w_production_powheg_0.lhe</ei>, <ei>w_production_powheg_1.lhe</ei>). For
441 these input files, the <code>main88.exe</code> executable can be run with
444 <code>./main88.exe main88.cmnd w_production myhepmc.hepmc</code>
445 <p/> to produce a file myhepmc.hepmc of UNLOPS merged HepMC event output.
446 Please refrain from adding input switches than invoke any other merging
447 scheme (e.g. <code>Merging:doKTMerging</code>) into the input file that you
448 want to use in conjunction with <code>main88.cc</code>.
450 <p/> In the following, we will explain <code>main88.cc</code> in depth. To
451 not be overly repetitive, we will at times refer to the relevant parts in the
452 discussion of <code>main87.cc</code>. Users who are willing to accept the
453 default choices do not need to know all details, but are still encouraged to
456 <h4>Program flow</h4>
458 <code>main88.cc</code> can be divided into five steps:
459 <p/> 1. Estimate the cross section for
460 tree-level and NLO samples <ei>after</ei> the merging scale cut.
461 <p/> 2. Produce reweighted tree-level events,
462 which do not contain <ei>α<sub>s</sub><sup>0</sup></ei>- and
463 <ei>α<sub>s</sub><sup>1</sup></ei>-terms.
464 <p/> 3. Add POWHEG NLO events.
465 <p/> 4. Subtract integrated, reweighted
466 tree-level events, to ensure that the inclusive NLO cross section remains
467 intact upon inclusion of multi-jet tree-level events.
468 <p/> 5. Subtract integrated POWHEG NLO
469 events, to ensure that the inclusive NLO cross section remains
470 intact upon inclusion of multi-jet tree-level events.
472 <p/> The estimation of cross sections after the application of the merging
473 scale cut is nearly identical to the first step in <code>main87.cc</code>, and
474 we refer to the first paragraph of the "Program flow" discussion for
475 <code>main87.cc</code> for details. For <code>main88.cc</code>, the flags
476 <code>Merging:doUNLOPSTree</code> or <code>Merging:doUNLOPSLoop</code> supply
477 the merging scale definition used in the cross section estimation.
479 <p/> After the cross section estimation step, <code>main88.cc</code> proceeds
480 to perform the actual NLO merging. The discussion of K-factors given in the
481 NL<sup>3</sup> section (i.e. of <code>Merging:kFactor0j</code>,
482 <code>Merging:kFactor1j</code> and <code>Merging:kFactor2j</code>) also
483 applies to <code>main88.cc</code>. Although UNLOPS is considerably more stable
484 than NL<sup>3</sup> upon changing the K-factors, we do not recommend the
487 <p/> The production of UNLOPS-merged events with <code>main88.cc</code> starts
488 by generating reweighted tree-level events. The processing of tree-level
489 events can be invoked by setting the following flag.
491 <flag name="Merging:doUNLOPSTree" default="off">
492 This switch will allow the generation of the weight that should be applied to
493 tree-level events in the UNLOPS merging scheme. Please note that, in
494 order for this to work smoothly, the switches
495 <code>Merging:doUNLOPSLoop</code>, <code>Merging:doUNLOPSSubt</code> and
496 <code>Merging:doUNLOPSSubtNLO</code> have to be turned off. As for the
497 estimation of cross sections, it is <ei>mandatory</ei> to set
498 the correct value of <code>Merging:nRequested</code>.
502 The weight of tree-level events is returned by the function
503 <strong>double Info::mergingWeightNLO()</strong>. When printing
504 (or histogramming) NLO merged events, this weight, multiplied with the
505 estimated cross section of the current event sample, should be used as event
506 weight (or weight of histogram bins). For
507 <code>Merging:doUNLOPSTree = on</code>,
508 the weight <strong>double Info::mergingWeightNLO()</strong> contains the
509 UMEPS weight, subtracted, if necessary, by
510 <ei>α<sub>s</sub><sup>0</sup></ei>- and
511 <ei>α<sub>s</sub><sup>1</sup></ei>-terms. This weight can become
512 negative. As an example, assume that we attempt an UNLOPS merging of W + 0 jet
513 and W + 1 jet at NLO accuracy, and with W + 2 jets at tree-level accuracy.
514 This weight will then be
515 <p/> <ei>Info::mergingWeightNLO() = UMEPS-weight for one jet
516 - <ei>α<sub>s</sub><sup>0</sup></ei>-terms
517 - <ei>α<sub>s</sub><sup>1</sup></ei>-terms
518 </ei> for events in the one-jet sample, and
519 <p/> <ei>Info::mergingWeightNLO() = UMEPS-weight for two jets </ei>
520 for events in the two-jet sample.
522 <p/> After reweighted tree-level events have been generated,
523 <code>main88.cc</code> processes the POWHEG NLO input files. This is
524 facilitated by the following switch.
526 <flag name="Merging:doUNLOPSLoop" default="off">
527 This switch will allow the processing of POWHEG NLO events in the
528 UNLOPS merging scheme. Please note that, in order for this to work
529 smoothly, the switches <code>Merging:doUNLOPSTree</code>,
530 <code>Merging:doUNLOPSSubt</code> and <code>Merging:doUNLOPSSubtNLO</code>
531 have to be turned off. As for the estimation of cross sections, it is
532 <ei>mandatory</ei> to set the correct value of
533 <code>Merging:nRequested</code>.
537 The NLO merging weight of the events can be accessed by
538 calling the function <strong>double Info::mergingWeightNLO()</strong>. This
539 weight should also be used when printing (or histogramming) events.
540 For <code>Merging:doUNLOPSLoop = on</code>,
541 the weight <strong>double Info::mergingWeightNLO()</strong> is either one or
542 zero (see Appendix E in <ref>Lon13</ref>).
545 After processing the POWHEG NLO events, <code>main88.cc</code> continues
546 by generating the reweighted subtraction terms of UMEPS. This part is
547 implemented by setting the following flag.
549 <flag name="Merging:doUNLOPSSubt" default="off">
550 This switch will allow the processing of tree-level events, to produce UMEPS
551 subtraction terms for the UNLOPS merging scheme. Please note
552 that, in order for this to work smoothly, the switches
553 <code>Merging:doUNLOPSTree</code>, <code>Merging:doUNLOPSLoop</code> and
554 <code>Merging:doUNLOPSSubtNLO</code> have to be turned off.
555 As for the estimation of cross sections, it is <ei>mandatory</ei> to set the
556 correct value of <code>Merging:nRequested</code>. Furthermore, it is necessary
557 to set the value of <code>Merging:nRecluster</code> to one.
560 <p/>By using this switch, <code>main88.cc</code> ensures that the inclusive
561 cross section is preserved. At variance with UMEPS however, the event weight
562 contains the UMEPS weight, subtracted, if necessary, by
563 <ei>α<sub>s</sub><sup>+0</sup></ei>- and
564 <ei>α<sub>s</sub><sup>1</sup></ei>-terms. Otherwise,
565 <ei>α<sub>s</sub><sup>n+0</sup></ei>- and
566 <ei>α<sub>s</sub><sup>n+1</sup></ei>-terms of the UMEPS procedure would
567 be introduced, although our goal is to describe all
568 <ei>α<sub>s</sub><sup>n+0</sup></ei>- and
569 <ei>α<sub>s</sub><sup>n+1</sup></ei>-terms by n-jet POWHEG input.
570 The weight of these integrated, subtractive tree-level events is, as always,
571 returned by the function <strong>double Info::mergingWeightNLO()</strong>.
572 When printing (or histogramming) NLO merged events, this weight, multiplied
573 with the estimated cross section of the current event sample, and with <ei>
574 -1</ei>, should be used
575 as event weight (or weight of histogram bins). As for the case of tree-level
576 events in UNLOPS, this weight can become negative.
577 For the example given before, i.e. attempting an UNLOPS merging of
578 W + 0 jet and W + 1 jet at NLO accuracy, and with
579 W + 2 jets at tree-level accuracy, this weight will be
580 <p/> <ei>Info::mergingWeightNLO() = UMEPS-weight for the integrated
581 one-jet sample - <ei>α<sub>s</sub><sup>0</sup></ei>-terms
582 - <ei>α<sub>s</sub><sup>1</sup></ei>-terms
583 </ei> for events in the integrated one-jet sample, and
584 <p/> <ei>Info::mergingWeightNLO() = UMEPS-weight for the integrated
586 for events in the integrated two-jet sample.
588 <p/>This choice of weights already
589 incorporates the fact that we have implemented the "inclusive scheme" of
590 <ref>Lon13</ref>, meaning that the "explicit phase space subtractions" of
591 NL<sup>3</sup> are (partially) included though these weights.
593 <p/> To ensure that the NLO inclusive cross section is unchanged, UNLOPS
594 further requires the introduction of another sample. If POWHEG NLO events with
595 one or more jets are included, it is necessary to subtract these samples
596 in an integrated form. In <code>main88.cc</code>, this is done by setting the
599 <flag name="Merging:doUNLOPSSubtNLO" default="off">
600 This switch will allow the processing of POWHEG NLO events, to produce NLO
601 subtraction terms for the UNLOPS merging scheme. Please note
602 that, in order for this to work smoothly, the switches
603 <code>Merging:doUNLOPSTree</code>, <code>Merging:doUNLOPSLoop</code> and
604 <code>Merging:doUNLOPSSubt</code> have to be turned off.
605 As for the estimation of cross sections, it is <ei>mandatory</ei> to set the
606 correct value of <code>Merging:nRequested</code>. Furthermore, it is necessary
607 to set the value of <code>Merging:nRecluster</code> to one.
610 <p/> This sample also provides some "explicit phase space subtractions" of
611 NL<sup>3</sup>, which are necessary because we implemented the
612 "inclusive scheme" of <ref>Lon13</ref>. Let us again look at the example of
613 UNLOPS merging of W + 0 jet and W + 1 jet at NLO accuracy.
614 The integrated W + 1 jet NLO events, which are produced by the setting
615 <code>Merging:doUNLOPSSubtNLO = on</code>, contain a tree-level part. This part
616 will exactly cancel the real-emission events with one jet above the merging
617 scale in the W + 0 jet NLO events.
620 The NLO merging weight of these "integrated" events can be accessed by
621 calling the function <strong>double Info::mergingWeightNLO()</strong>. This
622 weight should also be used when printing (or histogramming) events.
623 For <code>Merging:doUNLOPSSubtNLO = on</code>,
624 the weight <strong>double Info::mergingWeightNLO()</strong> is either one or
625 zero (see Appendix E in <ref>Lon13</ref>).
627 <p/> After these five steps (estimation of cross sections, tree-level
628 processing, POWHEG processing, integrated tree-level processing,
629 integrated POWHEG processing) we have produced a UNLOPS-merged HepMC
630 event file. <code>main88.cc</code> finishes by returning the
631 UNLOPS-merged total cross section.
635 <h3>NLO merging and "exclusive" NLO inputs</h3>
637 Currently, both sample main programs for NLO merging (<code>main87.cc</code>
638 and <code>main88.cc</code>) are intended for "inclusive" POWHEG input.
639 Inclusive input means that all real emission phase space points are included
640 in the POWHEG output files. In order to avoid double counting with
641 higher-multiplicity matrix elements, it is then necessary remove phase space
642 points with too many jets from the real-emission configurations.
643 This can be done by introducing explicit phase space subtractions. Another
644 way of removing the undesired configurations is by implementing a cut in the
645 NLO generator. This is not a completely trivial task, since it is necessary
646 to ensure numerical stability and the correct cancellation of (finite) dipole
647 regularisation terms. One way of producing such exclusive NLO output is by
648 setting the (tree-level) real-emission matrix element in the NLO generator to
649 zero if the real-emission phase space point contains too many jets above the
650 merging scale. This will however not be numerically stable for too low merging
653 <p/><ei> We should be very clear that using exclusive NLO input is not
654 recommended, since it requires hacking the NLO generator. Only for the expert
655 user, we briefly summarise the necessary changes for using exclusive
658 <p/> For the moment, assume that the NLO input has been produced in an
659 "exclusive" way. This input can then be processed by some trivial changes in
660 <code>main87.cc</code>: estimate the cross section for tree-level and NLO
661 samples <ei>after</ei> the merging scale cut, still using inclusive NLO
662 samples, remove the last part of <code>main87.cc</code>, i.e. the part that
663 produces explicit phase space subtractions, and use the exclusive NLO files as
664 input files for the processing of "POWHEG NLO files".
666 <p/> The changes to <code>main88.cc</code> (implementing UNLOPS) are slightly
667 more complicated. This is the case because the weights of integrated
668 tree-level samples change when using exclusive input, as can be seen in
669 Appendix D in <ref>Lon13</ref>. The correct weights can be produced by Pythia
670 by using the following flag.
672 <flag name="Merging:doUNLOPSTilde" default="off">
673 This flag allows the UNLOPS machinery to produce the event weights if
674 exclusive NLO input is used for the merging. This flag should be set to "on"
675 directly after the cross section estimates have been produced.
678 <p/> Then, it is necessary to add code for processing another sample to
679 <code>main88.cc</code>, since when using exclusive inputs, it is also
680 necessary to enforce two integrations on tree-level events (the
681 "↑"-contributions in Appendix D of <ref>Lon13</ref>). This can be
682 achieved by adding the following code at the end of <code>main88.cc</code>.
685 cout << endl << endl << endl;
686 cout << "Shower subtractive events" << endl;
688 // Switch on processing of counter-events.
689 pythia.settings.flag("Merging:doUNLOPSTree",false);
690 pythia.settings.flag("Merging:doUNLOPSLoop",false);
691 pythia.settings.flag("Merging:doUNLOPSSubt",true);
692 pythia.settings.flag("Merging:doUNLOPSSubtNLO",false);
693 pythia.settings.mode("Merging:nRecluster",2);
696 njetcounterCT = nMaxCT;
697 iPathSubt = iPath + "_tree";
699 while(njetcounterCT >= 2){
701 // From njet, choose LHE file
703 in << "_" << njetcounterCT << ".lhe";
704 string LHEfile = iPathSubt + in.str();
706 cout << endl << endl << endl
707 << "Start subtractive treatment for " << njetcounterCT << " jets\n"
708 << "Recluster at least 2 times" << endl;
710 pythia.readString("Beams:frameType = 4");
711 pythia.settings.word("Beams:LHEF", LHEfile);
712 pythia.settings.mode("Merging:nRequested", njetcounterCT);
714 // Remember position in vector of cross section estimates.
715 int iNow = sizeLO-1-njetcounterCT;
717 // Start generation loop
718 for( int iEvent=0; iEvent < nEvent; ++iEvent ){
720 // Generate next event
721 if( !pythia.next() ) {
722 if( pythia.info.atEndOfFile() ) break;
726 // Get event weight(s).
727 double weightNLO = pythia.info.mergingWeightNLO();
728 double evtweight = pythia.info.weight();
729 weightNLO *= evtweight;
730 // Do not print zero-weight events.
731 if ( weightNLO == 0. ) continue;
733 // Construct new empty HepMC event.
734 HepMC::GenEvent* hepmcevt = new HepMC::GenEvent();
735 // Get correct cross section from previous estimate.
736 double normhepmc = -1*xsecLO[iNow] / nAcceptLO[iNow];
737 // Set hepmc event weight.
738 hepmcevt->weights().push_back(weightNLO*normhepmc);
740 ToHepMC.fill_next_event( pythia, hepmcevt );
741 // Add the weight of the current event to the cross section.
742 sigmaTotal += weightNLO*normhepmc;
743 errorTotal += pow2(weightNLO*normhepmc);
744 // Report cross section to hepmc.
745 HepMC::GenCrossSection xsec;
746 xsec.set_cross_section( sigmaTotal*1e9, pythia.info.sigmaErr()*1e9 );
747 hepmcevt->set_cross_section( xsec );
748 // Write the HepMC event to file. Done with it.
749 ascii_io << hepmcevt;
752 } // end loop over events to generate
754 // print cross section, errors
757 // Restart with ME of a reduced the number of jets
758 if( njetcounterCT > 2 )
768 <!-- Copyright (C) 2013 Torbjorn Sjostrand -->