]>
Commit | Line | Data |
---|---|---|
63ba5337 | 1 | |
2 | <html> | |
3 | <head> | |
4 | <title>Matrix Element Merging</title> | |
5 | <link rel="stylesheet" type="text/css" href="pythia.css"/> | |
6 | <link rel="shortcut icon" href="pythia32.gif"/> | |
7 | </head> | |
8 | <body> | |
9 | ||
10 | <script language=javascript type=text/javascript> | |
11 | function stopRKey(evt) { | |
12 | var evt = (evt) ? evt : ((event) ? event : null); | |
13 | var node = (evt.target) ? evt.target :((evt.srcElement) ? evt.srcElement : null); | |
14 | if ((evt.keyCode == 13) && (node.type=="text")) | |
15 | {return false;} | |
16 | } | |
17 | ||
18 | document.onkeypress = stopRKey; | |
19 | </script> | |
20 | <?php | |
21 | if($_POST['saved'] == 1) { | |
22 | if($_POST['filepath'] != "files/") { | |
23 | echo "<font color='red'>SETTINGS SAVED TO FILE</font><br/><br/>"; } | |
24 | else { | |
25 | echo "<font color='red'>NO FILE SELECTED YET.. PLEASE DO SO </font><a href='SaveSettings.php'>HERE</a><br/><br/>"; } | |
26 | } | |
27 | ?> | |
28 | ||
29 | <form method='post' action='MatrixElementMerging.php'> | |
30 | ||
31 | <h2>Matrix Element Merging</h2> | |
32 | ||
33 | CKKW-L merging [<a href="Bibliography.php" target="page">Lon01</a>] allows for a consistent merging of parton | |
34 | showers with | |
35 | matrix elements to include multiple well-separated partons. The | |
36 | algorithm implemented in PYTHIA is described in [<a href="Bibliography.php" target="page">Lon11</a>]. To | |
37 | perform matrix element merging, the user has to supply LHE | |
38 | files [<a href="Bibliography.php" target="page">Alw07</a>] for the hard process and the corresponding | |
39 | process with up to N additional jets. | |
40 | ||
41 | <p/> The usage of the merging procedure is illustrated in a few | |
42 | example main programs | |
43 | (<code>main81.cc</code>, <code>main82.cc</code>, | |
44 | <code>main83.cc</code> and <code>main84.cc</code>, together with the | |
45 | input files <code>main81.cmnd</code>, <code>main82.cmnd</code> and | |
46 | <code>main84.cmnd</code>). These examples should of course only serve | |
47 | as an illustration, and as such will not make use of the merging in | |
48 | all possible ways. For full generality, the example programs link to | |
49 | LHAPDF, FastJet and HepMC. Of course the user is welcome to remove | |
50 | these dependencies. To remove the FastJet dependence, the functions | |
51 | calculating example observables have to be deleted. Removing the | |
52 | LHAPDF dependence requires changing the cmnd input files to choose an | |
53 | inbuilt PDF, as outlined in the | |
54 | <a href="PDFSelection.html" target="page">PDF documentation</a>. The | |
55 | HepMC dependence can be removed by erasing the code allowing for HepMC | |
56 | output. | |
57 | ||
58 | <p/> Please note that a detailed tutorial on merging in Pythia is available | |
59 | from | |
60 | <strong>http://home.thep.lu.se/~torbjorn/pythia8/mergingworksheet8160.pdf | |
61 | </strong> | |
62 | ||
63 | <p/> Three very short LHE files (<code>w+_production_lhc_0.lhe</code>, | |
64 | <code>w+_production_lhc_1.lhe</code>, <code>w+_production_lhc_2.lhe</code>) | |
65 | are included in the distribution. These files are not intended for | |
66 | physics studies, but only serve as input for the example main | |
67 | programs. For realistic studies, the user has to supply LHE files. | |
68 | ||
69 | <p/> In the generation of LHE files, the value of the factorisation | |
70 | scale used in the PDFs is not important, since the cross section will | |
71 | be multiplied by ratios of PDFs to adjust to the PYTHIA starting | |
72 | scales. The same is true for the renormalisation scale (and starting | |
73 | value <i>α<sub>s</sub>(M<sub>Z</sub>)</i>) used to evaluate | |
74 | <i>α<sub>s</sub></i>. Coupling and scale choices by the user | |
75 | will be transferred to the merging routines. | |
76 | ||
77 | <p/> Multi-jet events can suffer from infrared divergences in the | |
78 | calculation. Sensible matrix element generator (MEG) outputs should not | |
79 | contain phase space points in which the calculation is ill-defined, meaning | |
80 | infrared regions need to be removed by cuts. This is most conveniently done | |
81 | by disallowing the MEG to produce partons below a | |
82 | minimal parton-parton separation in a certain jet algorithm. Using | |
83 | dedicated cuts to regularise MEG output is of course possible as well. Any | |
84 | regularisation criterion defines the matrix element region: The parts of | |
85 | phase space in which the fixed order calculation is considered valid and | |
86 | preferable to the parton shower. Matrix element merging is combining | |
87 | MEG events in the matrix element region with parton shower events in regions | |
88 | outside the regularisation cut (often called parton shower region). Because | |
89 | the regularisation cut defines a boundary between the matrix element | |
90 | and parton shower regions, i.e. the regions to be merged into one inclusive | |
91 | sample, it is usually called <i> merging scale </i>. Since many different | |
92 | cut choices may regularise the MEG calculation, many different merging scale | |
93 | definitions are possible. A few standard choices are listed below, as well as | |
94 | documentation on how to use a user-defined cut criterion. In combining matrix | |
95 | element and parton shower regions, the CKKW-L prescription tries to minimise | |
96 | the dependence on the merging scale. This can only be achieved if the | |
97 | combination of MEG events and parton shower populates the whole phase space. | |
98 | Additional cuts on the partons in the LHEF generation should hence be | |
99 | avoided as much as possible, meaning that the merging scale cut should always | |
100 | pose a more stringent cut than all other cuts on the partons. Of course, if | |
101 | the hard process itself is divergent, cuts need to be made. However, this | |
102 | should be chosen in such a way as to not exclude regions that will be | |
103 | available to the matrix elements with additional jets. An example is QCD | |
104 | di-jet production with additional jets: Say the <i>2 -> 2</i> process is | |
105 | regularised with a <i>pTmin</i> cut of pTminCut = 100 GeV, and | |
106 | the <i>2 - >3</i> sample is regularised with a <i>kTmin</i>-cut of | |
107 | kTminCut = 50 GeV. This would mean that when reclustering | |
108 | the emission in the 2 -> 3 sample, we could end up with a | |
109 | pT value <i>pTminNow</i> of the 2 -> 2 configuration with | |
110 | <i>pTminCut > pTminNow</i>, which is excluded in the | |
111 | 2 -> 2 sample. Thus, the 2 -> 3 sample will include a | |
112 | Sudakov factor not included in the 2 -> 2 sample, resulting | |
113 | in merging scale dependencies. Such dependencies can be avoided if | |
114 | the additional cuts on the hard process are minimal. | |
115 | ||
116 | <p/> Of course, additional cuts on electroweak particles are | |
117 | allowed. These should be the same for all samples with | |
118 | <i>0 <= n <= N</i> additional partons. | |
119 | ||
120 | <p/> If it is not possible to generate LHE files with minimal cuts, | |
121 | the user can choose to use the <code>MergingHooks</code> structures in | |
122 | order to decide how much influence to attribute to parton shower | |
123 | histories in which the reclustered lowest multiplicity process does | |
124 | not pass the matrix element cuts. This is described below. | |
125 | ||
126 | <p/> When generating LHE files, we advise against putting | |
127 | unstable particles (e.g. massive gauge bosons) in the final state. | |
128 | Rather, specify a resonance by its decay products, e.g. if Les Houches | |
129 | events for the <i>pp → Z + jets → e+e- + jets</i> process | |
130 | are desired, generate the matrix element events with the <i>Z</i> decay | |
131 | included. From a physical point of view, on-shell final massive gauge | |
132 | bosons should not be considered part of a hard process, since only | |
133 | the boson decay products will be detectable. Furthermore, | |
134 | non-narrow-width approximation contributions are not present if the | |
135 | ME generator only produces on-shell bosons. Interference effects | |
136 | between different production channels for the decay products would | |
137 | also be neglected. These points seem an unnecessary restriction on | |
138 | the accuracy of the ME calculation. In addition, there is a | |
139 | technical reason for this strategy. Since some matrix element | |
140 | generators choose to put additional information on intermediate | |
141 | bosons into Les Houches events, depending on if they pass a certain | |
142 | criterion (e.g. being close to the mass shell), without exact | |
143 | knowledge of this criterion, the only feasible way of bookkeeping the | |
144 | hard process is by identifying outgoing decay products. | |
145 | ||
146 | <p/> Despite these considerations, (massive) gauge bosons in the final state | |
147 | are allowed in the hard process definition. This is useful particularly for | |
148 | Higgs physics, when different decays of the Higgs boson need to be simulated | |
149 | after the LHEF generation. | |
150 | ||
151 | <p/> For all merging purposes, processes with different charge of | |
152 | outgoing leptons are considered different processes. That means | |
153 | e.g. that <i>e+ν<sub>e</sub>+ jets</i> and | |
154 | <i>e-ν̄<sub>e</sub> + jets</i> | |
155 | are considered independent processes. If the user wishes to generate | |
156 | distributions including effects of more than one process, merged | |
157 | samples for all independent processes should be generated separately | |
158 | and added afterwards. Alternatively, to combine simple processes, | |
159 | combined LHE files can be used in conjunction with flexible containers (see | |
160 | below). | |
161 | ||
162 | <p/> When the matrix element merging is used to produce HepMC | |
163 | [<a href="Bibliography.php" target="page">Dob01</a>] files to be analysed with RIVET [<a href="Bibliography.php" target="page">Buc10</a>], | |
164 | special care needs to taken in how the cross section is read by RIVET | |
165 | (see below). | |
166 | ||
167 | <p/> To specify the merging conditions, additionally information on | |
168 | the merging scale value and the functional definition of the merging | |
169 | scale is needed. A few standard definitions of merging scales are | |
170 | available. We hope this makes the user interface less cumbersome. | |
171 | ||
172 | <p/> Different choices intrinsic to the CKKW-L merging procedure might | |
173 | be relevant for the user as well. The base | |
174 | class <code>MergingHooks</code> gives the user the opportunity to | |
175 | define the functional form of the merging scale. In the following, | |
176 | the usage of the merging machinery to consistently include LHE files | |
177 | with additional jets into PYTHIA will be discussed. | |
178 | ||
179 | <br/><br/><hr/> | |
180 | <h3>Merging scale definitions</h3> | |
181 | ||
182 | <p/> The quickest way to include processes with additional jets is to | |
183 | produce LHE files with one of the standard ways to define the merging | |
184 | scale. Three standard ways to define a merging scale (minimal <i>kT</i>, | |
185 | minimal evolution <i>pT</i> and by three cuts) are implemented. All of these | |
186 | prescriptions are equivalent - different definitions have only been introduced | |
187 | for the convenience of users, who might be limited by which cuts can be used | |
188 | in the generation of LHE files. Below, we describe how to switch on and use | |
189 | these different merging scale definitions. | |
190 | ||
191 | <h4>Merging with merging scale defined in kT:</h4> | |
192 | ||
193 | <br/><br/><strong>Merging:doKTMerging</strong> <input type="radio" name="1" value="on"><strong>On</strong> | |
194 | <input type="radio" name="1" value="off" checked="checked"><strong>Off</strong> | |
195 | (<code>default = <strong>off</strong></code>)<br/> | |
196 | If the additional jets in the LHE files have been regulated by | |
197 | a <i>kT</i> cut, the user can supply the merging scale definition by | |
198 | setting this flag to on. <i>kT</i> here and below means cutting on | |
199 | Durham <i>kT</i> for <i>e+e-</i> collisions, and cutting on | |
200 | longitudinally invariant <i>kT</i> for hadronic collisions. Please note | |
201 | that this particular merging scale definition will check <i>kT</i> between | |
202 | all pairs of <i>u,d,c,s,b,g</i> partons. | |
203 | ||
204 | ||
205 | </p> | |
206 | Currently, the name longitudinally invariant <i>kT</i> is used | |
207 | for a few jet recombination algorithms with slightly different | |
208 | jet measures. A specific form can be chosen by setting the switch | |
209 | ||
210 | <br/><br/><table><tr><td><strong>Merging:ktType </td><td> (<code>default = <strong>1</strong></code>; <code>minimum = 1</code>; <code>maximum = 3</code>)</td></tr></table> | |
211 | Precise functional definition of longitudinally | |
212 | invariant <ei>kT</ei>. For e+e- collisions, <ei>Durham kT</ei> is | |
213 | always defined by the square root of <ei>min{ 2*min[ </sub> | |
214 | E<sub>i</sub><sup>2</sup>, E<sub>j</sub><sup>2</sup>] * [ 1 - | |
215 | cosθ<sub>ij</sub>] }</ei>, so that this switch will have no effect. | |
216 | <br/> | |
217 | <input type="radio" name="2" value="1" checked="checked"><strong>1 </strong>: Longitudinally invariant <ei>kT</ei> is defined by the square root of the minimum of minimal jet kinematic <ei>pT</ei> (<ei>p<sub>Tkin,min</sub><sup>2</sup> = min{ p<sub>T,i</sub><sup>2</sup> } </ei>) and <ei>p<sub>Tlon,min</sub><sup>2</sup> = min{ min[ p<sub>T,i</sub><sup>2</sup>, p<sub>T,j</sub><sup>2</sup>] * [ (Δy<sub>ij</sub>)<sup>2</sup> + (Δφ<sub>ij</sub>)<sup>2</sup> ] / D<sup>2</sup> }</ei> , i.e. <ei>kT = min{ √p<sub>Tkin,min</sub><sup>2</sup>, √p<sub>Tlon,min</sub><sup>2</sup> }</ei> for hadronic collisions. Note that the true rapidity of partons is used. <br/> | |
218 | <input type="radio" name="2" value="2"><strong>2 </strong>: Longitudinally invariant <ei>kT</ei> is defined by the square root of the minimum of minimal jet kinematic <ei>pT</ei> (<ei>p<sub>Tkin,min</sub><sup>2</sup> = min{ p<sub>T,i</sub><sup>2</sup> } </ei>) and <ei>p<sub>Tlon,min</sub><sup>2</sup> = min{ min[ p<sub>T,i</sub><sup>2</sup>, p<sub>T,j</sub><sup>2</sup>] * [ (Δη<sub>ij</sub>)<sup>2</sup> + (Δφ<sub>ij</sub>)<sup>2</sup> ] / D<sup>2</sup> }</ei>, i.e. <ei>kT = min{ √p<sub>Tkin,min</sub><sup>2</sup>, √p<sub>Tlon,min</sub><sup>2</sup> }</ei> for hadronic collisions. Note that the pseudorapidity of partons is used. <br/> | |
219 | <input type="radio" name="2" value="3"><strong>3 </strong>: Longitudinally invariant <ei>kT</ei> is defined by the square root of the minimum of minimal jet kinematic <ei>pT</ei> (<ei>p<sub>Tkin,min</sub><sup>2</sup> = min{ p<sub>T,i</sub><sup>2</sup> } </ei>) and <ei>p<sub>Tlon,min</sub><sup>2</sup> = min{ min[ p<sub>T,i</sub><sup>2</sup>, p<sub>T,j</sub><sup>2</sup>] * [ cosh(Δη<sub>ij</sub>) - cos(Δφ<sub>ij</sub>) ] / D<sup>2</sup> } </ei>, i.e. <ei>kT = min{ √p<sub>Tkin,min</sub><sup>2</sup> , √p<sub>Tlon,min</sub><sup>2</sup> }</ei> for hadronic collisions. <br/> | |
220 | ||
221 | <br/><br/><table><tr><td><strong>Merging:nJetMax </td><td></td><td> <input type="text" name="3" value="0" size="20"/> (<code>default = <strong>0</strong></code>; <code>minimum = 0</code>)</td></tr></table> | |
222 | Maximal number of additional jets in the matrix element | |
223 | ||
224 | ||
225 | <br/><br/><table><tr><td><strong>Merging:TMS </td><td></td><td> <input type="text" name="4" value="0.0" size="20"/> (<code>default = <strong>0.0</strong></code>)</td></tr></table> | |
226 | The value of the merging scale. The name is inspired by the scale in | |
227 | evolution equations, which is often called 't', and the suffix 'MS' stands | |
228 | for merging scale. In the particular case of <i>kT</i>-merging, this | |
229 | would be the value of the <i>kT</i>-cut in GeV. For any merging scale | |
230 | definition, this input is considered the actual value of the merging | |
231 | scale. | |
232 | ||
233 | ||
234 | <br/><br/><table><tr><td><strong>Merging:Process </td><td></td><td> <input type="text" name="5" value="void" size="20"/> (<code>default = <strong>void</strong></code>)</td></tr></table> | |
235 | The string specifying the hard core process, in MG4/ME notation. | |
236 | ||
237 | ||
238 | </p> | |
239 | If e.g. <i>W + jets</i> merging should be performed, set this to | |
240 | <code>pp>e+ve</code> (<i>without white spaces or quotation marks</i>). | |
241 | This string may contain resonances in the MG/ME notation, e.g. for merging | |
242 | <i>pp→Z W<sup>+</sup>→q q̄ e+ν<sub>e</sub> + jets</i>, | |
243 | the string <code>pp>(z>jj)(w+>e+ve)</code> would be applicable. | |
244 | ||
245 | <p/> | |
246 | A lot more flexible hard process definitions are possible. To not dwell too | |
247 | much on these details here, we will come back to the process string at the end | |
248 | of this section. | |
249 | ||
250 | ||
251 | <br/><br/><strong>Merging:doMGMerging</strong> <input type="radio" name="6" value="on"><strong>On</strong> | |
252 | <input type="radio" name="6" value="off" checked="checked"><strong>Off</strong> | |
253 | (<code>default = <strong>off</strong></code>)<br/> | |
254 | Even easier, but highly non-general, is to perform the merging with | |
255 | MadGraph/MadEvent-produced LHE files, with a merging scale defined by | |
256 | a <i>kT</i> cut. For this, set this switch to on. The merging scale | |
257 | value will be read from the +1 jet LHE file by searching for the | |
258 | string <code>ktdurham</code>, and extracting the value from <code> | |
259 | value = ktdurham</code>. Also, the hard process will be read from | |
260 | the +0 jet LHE file, from the line containing the string <code>@1</code> | |
261 | (the tag specifying the first process in the MadGraph process card). | |
262 | For this to work, PYTHIA should be initialised on LHE files called | |
263 | <code>NameOfYourLesHouchesFile_0.lhe</code> (+0 jet sample) and | |
264 | <code>NameOfYourLesHouchesFile_1.lhe</code> (+1 jet sample) and the | |
265 | same naming convention for LHE files with two or more additional jets. | |
266 | Since for this option, the merging scale value is read from the | |
267 | LHEF, no merging scale value needs to be supplied by setting <code> | |
268 | Merging:TMS </code>. Also, the hard process is read from LHEF, the | |
269 | input <code>Merging::Process</code> does not have to be defined. | |
270 | However, the maximal number of merged jets still has to be supplied by | |
271 | setting <code>Merging:nJetMax</code>. | |
272 | ||
273 | ||
274 | ||
275 | <h4>Merging with merging scale defined in Pythia evolution pT:</h4> | |
276 | ||
277 | If the LHE file has been regularised by cutting on the minimal Pythia evolution | |
278 | pT in the state, this can also be used as a merging scale right away. For this, | |
279 | change the switch | |
280 | ||
281 | <br/><br/><strong>Merging:doPTLundMerging</strong> <input type="radio" name="7" value="on"><strong>On</strong> | |
282 | <input type="radio" name="7" value="off" checked="checked"><strong>Off</strong> | |
283 | (<code>default = <strong>off</strong></code>)<br/> | |
284 | The merging scale is then defined by finding the minimal Pythia evolution pT | |
285 | between sets of radiator, emitted an recoiler partons. For this | |
286 | particular merging scale definition, <i>u,d,c,s,b,g</i> are considered | |
287 | partons. The Pythia evolution pT of a single three-parton set is defined by | |
288 | <p/> | |
289 | <i>pT<sub>evol</sub> = z<sub>ijk</sub>(1-z<sub>ijk</sub>) | |
290 | Q<sub>ij</sub><sup>2</sup></i> for FSR, where <i>i</i> is the radiating | |
291 | parton, <i>j</i> is the emitted parton and <i>k</i> is the recoiler, and | |
292 | <i> Q<sub>ij</sub><sup>2</sup> = | |
293 | (p<sub>i</sub> + p<sub>j</sub>)<sup>2</sup> </i>, and | |
294 | <i>z<sub>ijk</sub> = | |
295 | x<sub>i,jk</sub> / (x<sub>i,jk</sub> + x<sub>j,ik</sub>)</i> with | |
296 | <i>x<sub>i,jk</sub> = | |
297 | 2 p<sub>i</sub> (p<sub>i</sub> + p<sub>j</sub> + p<sub>k</sub>) | |
298 | / (p<sub>i</sub> + p<sub>j</sub> + p<sub>k</sub>)<sup>2</sup> </i> | |
299 | <p/> | |
300 | <i>pT<sub>evol</sub> = (1-z<sub>ijk</sub>) | |
301 | Q<sub>ij</sub><sup>2</sup></i> for ISR, where <i>i</i> is the radiating | |
302 | parton, <i>j</i> is the emitted parton and <i>k</i> is the second initial | |
303 | state parton, and | |
304 | <i> Q<sub>ij</sub><sup>2</sup> = | |
305 | -(p<sub>i</sub> - p<sub>j</sub>)<sup>2</sup> </i>, and | |
306 | <i>z<sub>ijk</sub> = | |
307 | (p<sub>i</sub> - p<sub>j</sub> + p<sub>k</sub>)<sup>2</sup> | |
308 | / (p<sub>i</sub> + p<sub>k</sub>)<sup>2</sup> </i>. | |
309 | ||
310 | <p/> | |
311 | When using this option, the merging scale is defined by the minimum | |
312 | <i>pT<sub>evol</sub></i> for all combinations of three partons in the event, | |
313 | irrespectively of flavour or colour-connections. The merging scale value will | |
314 | be read from the <code>Merging:TMS</code> parameter, so that this needs to be | |
315 | set just as in the case of the <i>kT</i>-merging prescription. Of course you | |
316 | will also need to set <code>Merging:Process</code> and the maximal number of | |
317 | additional matrix element jets <code>Merging:nJetMax</code>. | |
318 | ||
319 | ||
320 | <h4>Merging with merging scale defined by a combination of cuts:</h4> | |
321 | ||
322 | It is possible to regularise QCD divergences in a LHE file by applying cuts | |
323 | to the kinematical pT of jets (<i>pT<sub>i</sub></i>), combined with a cut on | |
324 | <i> ΔR<sub>ij</sub></i> between jets and a cut on invariant mass | |
325 | <i> Q<sub>ij</sub></i> of jet pairs. The combination of these standard cuts | |
326 | can also serve as a merging scale. For this, use this setting | |
327 | ||
328 | <br/><br/><strong>Merging:doCutBasedMerging</strong> <input type="radio" name="8" value="on"><strong>On</strong> | |
329 | <input type="radio" name="8" value="off" checked="checked"><strong>Off</strong> | |
330 | (<code>default = <strong>off</strong></code>)<br/> | |
331 | This switch will use cuts on (<i>pT<sub>i</sub></i>), | |
332 | <i> ΔR<sub>ij</sub></i> and | |
333 | <i> Q<sub>ij</sub></i> to define when parton shower emissions are allowed. | |
334 | Please note for this particular merging scale definition, only light jets | |
335 | (<i>u,d,c,s,g</i>) are checked. | |
336 | ||
337 | ||
338 | <p/> | |
339 | The values of the cuts will then be read from | |
340 | ||
341 | <br/><br/><table><tr><td><strong>Merging:QijMS </td><td></td><td> <input type="text" name="9" value="0.0" size="20"/> (<code>default = <strong>0.0</strong></code>)</td></tr></table> | |
342 | The value of the invariant mass cut <i> Q<sub>ij</sub></i> of pairs of final | |
343 | state partons used in the matrix element generation. | |
344 | ||
345 | ||
346 | <br/><br/><table><tr><td><strong>Merging:pTiMS </td><td></td><td> <input type="text" name="10" value="0.0" size="20"/> (<code>default = <strong>0.0</strong></code>)</td></tr></table> | |
347 | The value of the minimal transverse momentum cut <i> pT<sub>i</sub></i> on | |
348 | final state partons, as used in the matrix element generation. | |
349 | ||
350 | ||
351 | <br/><br/><table><tr><td><strong>Merging:dRijMS </td><td></td><td> <input type="text" name="11" value="0.0" size="20"/> (<code>default = <strong>0.0</strong></code>)</td></tr></table> | |
352 | The value of the minimal <i> ΔR<sub>ij</sub></i> separation between | |
353 | pairs of final state partons used in the matrix element generation, where | |
354 | <i> ΔR<sub>ij</sub><sup>2</sup> = (Δy<sub>ij</sub>)<sup>2</sup> + | |
355 | (Δφ<sub>ij</sub>)<sup>2</sup></i>. | |
356 | ||
357 | ||
358 | <p/> | |
359 | With knowledge of these values, and <code>Merging:doCutBasedMerging</code>, | |
360 | Pythia will use these cuts as a separation between matrix element phase space | |
361 | and parton shower region. If e.g. the Les Houches Events have been generated | |
362 | with the cuts <i> ΔR<sub>ij</sub> = 0.1 </i>, | |
363 | <i>pT<sub>i</sub>= 20 GeV</i> and <i> Q<sub>ij</sub> = 40 GeV</i>, set | |
364 | <code>Merging:QijMS=40.</code>, | |
365 | <code>Merging:pTjMS=20.</code>, | |
366 | <code>Merging:dRijMS=0.1</code> to perform a cut-based merging. Of course | |
367 | you will also need to set <code>Merging:Process</code> and the | |
368 | maximal number of additional matrix element jets | |
369 | <code>Merging:nJetMax</code>. | |
370 | ||
371 | <h4>Les Houches events outside the matrix element region</h4> | |
372 | ||
373 | </p> | |
374 | Before continuing, we would like to point out that in general, the user | |
375 | should make sure that the events in the Les Houches file are actually | |
376 | calculated using the regularisation cut definition and value(s) supplied to | |
377 | Pythia as merging scale definition and value(s). However, if LH files with | |
378 | a large number of events and loose merging scale cuts are available, it | |
379 | might be useful to choose a higher merging scale value, e.g. for merging | |
380 | scale variations as part of uncertainty assessments. If CKKW-L merging is | |
381 | enabled, Pythia will by default check if events read from Les Houches file | |
382 | are in the matrix element region as defined by the merging scale definition | |
383 | and merging scale value. Events outside the matrix element region will be | |
384 | discarded. To change this default behaviour, use the flag | |
385 | ||
386 | <br/><br/><strong>Merging:enforceCutOnLHE</strong> <input type="radio" name="12" value="on" checked="checked"><strong>On</strong> | |
387 | <input type="radio" name="12" value="off"><strong>Off</strong> | |
388 | (<code>default = <strong>on</strong></code>)<br/> | |
389 | This will check if the events read from LHE file are in the matrix element | |
390 | region as defined by the merging scale definition and value(s). If on, LHE | |
391 | input outside the matrix element region will be rejected. If off, every | |
392 | event is assumed to pass the merging scale cut. | |
393 | ||
394 | ||
395 | <h4>Defining the hard process</h4> | |
396 | ||
397 | To perform CKKW-L matrix element merging, the user has to decide on a hard | |
398 | process, and communicate this choice to Pythia. This is done by setting the | |
399 | input <strong>Merging:Process</strong> | |
400 | ||
401 | <p/> | |
402 | For single processes in the Standard Model or the MSSM, MG4/ME notation is | |
403 | applicable. However, for some purposes, using a single simple process | |
404 | string is not satisfactory. Mixed W<sup>+</sup> and W<sup>-</sup> events | |
405 | in a single LHE file is a common example. For this case, it would of course | |
406 | be perfectly allowed to perform twice, once for W<sup>+</sup> production and | |
407 | once for W<sup>-</sup> production, and then add the results. Nevertheless, it | |
408 | seems reasonable to alleviate difficulties by allowing for less restrictive | |
409 | hard process definitions. Two generalisations of the process tag are | |
410 | available: Containers and user-defined particle tags. The syntax of these | |
411 | settings is described below. | |
412 | ||
413 | <p/> | |
414 | In case you want multiple processes in a LHE file to be treated on equal | |
415 | footing (e.g. <i>W<sup>+</sup> + jets</i> and <i>W<sup>-</sup> + jets</i>), | |
416 | you should use flexible containers do specify the hard process. So far, we | |
417 | allow the use of the containers <code>LEPTONS</code>, <code>NEUTRINOS</code>, | |
418 | <code>BQUARKS</code>. If you use these containers, the hard process definition | |
419 | is relatively flexible, meaning that Pythia will attempt a merging of QCD jets | |
420 | for each event in the LHE file, and assume that all particles matching one of | |
421 | the containers are products of the hard process. This is best explained by | |
422 | examples. If you want to have both <i>pp → e+ ν<sub>e</sub> + jets</i> | |
423 | and <i>pp → e- ν̄<sub>e</sub> + jets</i> events in a single | |
424 | file, you can set <code>Merging:Process=pp>LEPTONS,NEUTRINOS</code> as hard | |
425 | process (note that for readability, you are allowed to use commata to separate | |
426 | container names). Combining e.g. the processes | |
427 | <i>pp → e+ ν<sub>e</sub></i> and | |
428 | <i>pp → μ+ ν<sub>μ</sub></i> is possible with the hard process | |
429 | definition <code>pp>LEPTONS,NEUTRINOS</code>. | |
430 | ||
431 | <p/> | |
432 | For maximal flexibility, the definition of the hard process by these containers | |
433 | does not mean that each Les Houches event needs to contain particles to match | |
434 | each container. It is enough if one container is matched. This means that | |
435 | with the string <code>pp>LEPTONS,NEUTRINOS</code>, you can immediately process | |
436 | <i>pp → e+ e- </i> events mixed with | |
437 | <i>pp → e+ ν<sub>e</sub></i> events, since particles matching at | |
438 | least one container can be found in both cases. Another example for the usage | |
439 | of containers is mixing <i>pp → e+ ν<sub>e</sub></i> and | |
440 | <i>pp → tt̄ → e+ ν<sub>e</sub> e- ν̄<sub>e</sub> | |
441 | bb̄</i>. This can be accommodated by the hard process string | |
442 | <code>Merging:Process=pp>LEPTONS,NEUTRINOS,BQUARKS</code>. | |
443 | ||
444 | <p/> | |
445 | There is however a conceptual limitation to containers: The hard process | |
446 | definition is necessary to ensure that when constructing lower multiplicity | |
447 | states (that will be used to calculate the correct merging weight), the | |
448 | structure of the hard process will be preserved. If e.g. we want the hard process | |
449 | to be <i>pp → Z → bb̄ </i>, we should ensure that the lowest | |
450 | multiplicity state contains a colour-singlet bb̄-pair. When | |
451 | reconstructing intermediate lower multiplicity states from multi-jet matrix | |
452 | elements, we should thus always be able to find at least one bb̄-pair. By | |
453 | mixing different processes in a LHE file, this requirement might already be | |
454 | violated at the level of Les Houches events. Flexible containers cannot give | |
455 | strong conditions which flavours should be preserved in the construction of | |
456 | the hard process. In order to avoid non-sensible results, it is hence <i> | |
457 | assumed that all</i> particles matching any of the containers will be part | |
458 | of the lowest multiplicity process. This implies that if you decide to use the | |
459 | <code>BQUARKS</code> container, all b-quarks in the LHE file will be | |
460 | interpreted as hard process particles, and never as additional radiation. | |
461 | ||
462 | <p/> | |
463 | Another way to specify the hard process particles is to explicitly define the | |
464 | particle names and identifiers. This is necessary if the matrix element merging | |
465 | in Pythia does not contain the particles of interest. To make sure that the | |
466 | hard process is still treated correctly, it is possible to define particles | |
467 | in the process string. If you e.g. want the hard process to contain a particle | |
468 | "zeta~" with PDG identifier "12345", produced in proton collisions, you | |
469 | have to include a user-defined particle tag by setting the process string to | |
470 | <code>pp>{zeta~,12345}</code>. The user-defined particle is enclosed in | |
471 | curly brackets, with syntax | |
472 | <code>{particle_name,particle_identifier}</code>, where "particle_name" | |
473 | and "particle_identifier" are the particle name and particle identifier used | |
474 | for this particle in the input LHE file. User-defined particles are only | |
475 | allowed in the final state. You are free to fix user-defined particles with | |
476 | more common ones, as long as user-defined particles are put before more common | |
477 | particles in the process string. This means that if you e.g. wanted the hard | |
478 | process to contain a graviton in association with a positron and an | |
479 | electron-neutrino, you have to define the hard process as | |
480 | <code>pp>{G,39}e+ve</code>. | |
481 | ||
482 | <p/> | |
483 | Below you can find a list of particles predefined in the merging. If you wish | |
484 | to include a hard process with different final state particles, you may use | |
485 | the "curly bracket notation" outlined above. | |
486 | ||
487 | <p/> | |
488 | The set of incoming particles us limited to: | |
489 | <code>e-</code> (electron), <code>e+</code> (positron), <code>mu-</code> (muon), | |
490 | <code>mu+</code> (antimuon), <code>p</code> (proton, container to hold all | |
491 | initial state coloured particles), <code>p~</code> (identical to | |
492 | <code>p</code> container). | |
493 | ||
494 | <p/> | |
495 | The following intermediate particles are allowed: | |
496 | <code>a</code> (photon), <code>z</code> (Z boson), | |
497 | <code>w-</code> (W<sup>-</sup> boson), <code>w+</code> (W<sup>+</sup> boson), | |
498 | <code>h</code> (scalar Higgs boson), <code>W</code> (container to hold both | |
499 | W<sup>-</sup> and W<sup>+</sup> boson), <code>t</code> (top quark), | |
500 | <code>t~</code> (anti-top), | |
501 | <code>dl</code>, <code>dl~</code>, <code>ul</code>, <code>ul~</code>, | |
502 | <code>sl</code>, <code>sl~</code>, <code>cl</code>, <code>cl~</code>, | |
503 | <code>b1</code>, <code>b1~</code>, <code>t1</code>, <code>t1~</code>, | |
504 | <code>dr</code>, <code>dr~</code>, <code>ur</code>, <code>ur~</code>, | |
505 | <code>sr</code>, <code>sr~</code>, <code>cr</code>, <code>cr~</code>, | |
506 | <code>b2</code>, <code>b2~</code>, <code>t2</code>, <code>t2~</code> (all MSSM | |
507 | squarks). | |
508 | ||
509 | <p/> | |
510 | We have pre-defined the outgoing particles: | |
511 | <code>e+</code>, <code>e-</code>, <code>ve~</code>, | |
512 | <code>ve</code>, <code>mu+</code>, <code>mu-</code>, | |
513 | <code>vm~</code>, <code>vm</code>, <code>ta+</code>, <code>ta-</code>, | |
514 | <code>vt~</code>, <code>vt</code> (all SM leptons and neutrinos), | |
515 | <code>j~</code> (container to hold all final state coloured particles), | |
516 | <code>j</code> (container to hold all final state coloured particles), | |
517 | <code>NEUTRINOS</code> (container to hold all final state neutrinos and | |
518 | anti-neutrinos), <code>LEPTONS</code> (container to hold all final state | |
519 | leptons and anti-leptons), <code>BQUARKS</code> (container to hold final | |
520 | state b-quarks), <code>d~</code>, <code>d</code>, <code>u~</code>, | |
521 | <code>u</code>, <code>s~</code>, <code>s</code>, <code>c~</code>, | |
522 | <code>c</code>, <code>b~</code>, <code>b</code>, <code>t~</code>, | |
523 | <code>t</code> (all SM quarks), <code>a</code>, <code>z</code>, | |
524 | <code>w-</code>, <code>w+</code> (all SM electro-weak bosons), | |
525 | <code>h</code> (scalar Higgs boson), <code>W</code> (container to hold both | |
526 | W<sup>-</sup> and W<sup>+</sup> boson), <code>n1</code> (MSSM neutralino), | |
527 | <code>dl~</code>, <code>dl</code>, <code>ul~</code>, <code>ul</code>, | |
528 | <code>sl~</code>, <code>sl</code>, <code>cl~</code>, <code>cl</code>, | |
529 | <code>b1~</code>, <code>b1</code>, <code>t1~</code>, <code>t1</code>, | |
530 | <code>dr~</code>, <code>dr</code>, <code>ur~</code>, <code>ur</code>, | |
531 | <code>sr~</code>, <code>sr</code>, <code>cr~</code>, <code>cr</code>, | |
532 | <code>b2~</code>, <code>b2</code>, <code>t2~</code>, <code>t2</code> | |
533 | (all MSSM squarks). Other outgoing particles are possible if you use the | |
534 | "curly bracket notation" described earlier. | |
535 | ||
536 | <br/><br/><hr/> | |
537 | <h3>Histogramming the events</h3> | |
538 | After the event has been processed, histograms for observables of interest | |
539 | need to be filled. In order to achieve good statistical accuracy for all jet | |
540 | multiplicities and all subprocesses contributing to one jet multiplicity, | |
541 | generally a fixed number of unit-weighted events is read from each Les | |
542 | Houches Event file. To then arrive at the correct prediction, for each of these | |
543 | events, histogram bins should be filled with the corresponding cross | |
544 | section, or weighted with unit weight and normalised at the end to | |
545 | the generated cross section for each jet multiplicity separately. | |
546 | ||
547 | <p/> Still another, even more important, event weight that has to | |
548 | applied on an event-by-event basis is the CKKW-L-weight. This | |
549 | corrective weight is the main outcome of the merging procedure and | |
550 | includes the correct no-emission probabilities, PDF weights and | |
551 | α<sub>s</sub> factors. This means that the merging | |
552 | implementation will generate weighted events. The CKKW-L-weight can be | |
553 | accessed by the following function: | |
554 | ||
555 | <p/><strong> double Info::mergingWeight() </strong> <br/> | |
556 | Returns the CKKW-L weight for the current event. | |
557 | ||
558 | <p/> Note that to avoid confusion, this function does not include the | |
559 | the weight of a phase space point (given | |
560 | by <strong>Info::weight()</strong>). This weight will differ from | |
561 | unity when reading in weighted Les Houches events. In this case, the | |
562 | full weight with which to fill histogram bins is | |
563 | <strong>Info::mergingWeight() * Info::weight()</strong>. | |
564 | ||
565 | <p/> Finally, to arrive at a correct relative normalisation of the | |
566 | contributions from different number of additional jets in the matrix | |
567 | element, each histogram should be rescaled with the accepted cross | |
568 | section given by | |
569 | <strong>Info::sigmaGen()</strong>. The accepted cross section includes | |
570 | the effect of vetoes generating Sudakov form factors for the matrix | |
571 | elements, and is in general only known after the run. | |
572 | ||
573 | <p/> This final step can of course be skipped if the accepted cross | |
574 | section had been estimated before the histogramming run, and histogram | |
575 | bins had instead been filled with the weight | |
576 | <strong>Info::mergingWeight() * σ<sub>est</sub>(number of | |
577 | additional jets in current ME sample)</strong>. This is the way HepMC | |
578 | events should be weighted to produce correct relative weights of | |
579 | events (see below, and particularly examine the example program | |
580 | <code>main84.cc</code>). | |
581 | ||
582 | <p/> Examples how to use these options are given in <code>main81.cc</code> | |
583 | (<i>kT</i> merging) and <code>main84.cc</code> (automatic MG/ME merging | |
584 | for RIVET usage). | |
585 | ||
586 | <br/><br/><hr/> | |
587 | <h3>Merging with user-defined merging scale function</h3> | |
588 | ||
589 | <p/> For all other merging scale definitions, the procedure is | |
590 | slightly more complicated, since the user has to write a small piece | |
591 | of code defining the merging scale. To allow for a user defined | |
592 | procedure, set the input | |
593 | ||
594 | <br/><br/><strong>Merging:doUserMerging</strong> <input type="radio" name="13" value="on"><strong>On</strong> | |
595 | <input type="radio" name="13" value="off" checked="checked"><strong>Off</strong> | |
596 | (<code>default = <strong>off</strong></code>)<br/> | |
597 | General user defined merging on/off. | |
598 | ||
599 | ||
600 | </p> | |
601 | Then, set | |
602 | the <strong>Merging:nJetMax</strong>, <strong>Merging:TMS</strong> | |
603 | and <strong>Merging:Process</strong> input as before. | |
604 | ||
605 | <p/> Since during execution, PYTHIA needs to evaluate the merging | |
606 | scale with the definition of the user, the user interface is designed | |
607 | in a way similar to the | |
608 | <code>UserHooks</code> strategy. The class controlling the merging | |
609 | scale definition is called <code>MergingHooks</code>. | |
610 | ||
611 | <h4>Initialisation</h4> | |
612 | ||
613 | <p/> To initialise the merging with user-defined merging scale, we | |
614 | should construct a class derived from <code>MergingHooks</code>, with | |
615 | a constructor and destructor | |
616 | ||
617 | <p/> | |
618 | <a name="method1"></a> | |
619 | <p/><strong>MergingHooks::MergingHooks() </strong> <br/> | |
620 | ||
621 | <a name="method2"></a> | |
622 | <p/><strong>virtual MergingHooks::~MergingHooks() </strong> <br/> | |
623 | ||
624 | The constructor and destructor do not need to do anything. | |
625 | ||
626 | <p/> For the class to be called during execution, a pointer to an | |
627 | object of the class should be handed in with the | |
628 | <br/><code><a href="ProgramFlow.html" target="page"> | |
629 | Pythia::setMergingHooksPtr( MergingHooks*)</a></code> method. | |
630 | ||
631 | An examples of this procedure are given in <code>main82.cc</code>. | |
632 | ||
633 | <h4>Defining a merging scale</h4> | |
634 | ||
635 | <p/> Then, in the spirit of the <code>UserHooks</code> class, the user | |
636 | needs to supply the process to be merged by defining a methods to | |
637 | evaluate the merging scale variable. | |
638 | ||
639 | <a name="method3"></a> | |
640 | <p/><strong>virtual double MergingHooks::tmsDefinition(const Event& event) </strong> <br/> | |
641 | This method will have to calculate the value of the merging scale | |
642 | defined in some variable from the input event record. An example of | |
643 | such a function is given in <code>main82.cc</code>. | |
644 | ||
645 | ||
646 | <p/> The base class <code>MergingHooks</code> contains many functions | |
647 | giving information on the hard process, to make the definition of the | |
648 | merging scale as easy as possible: | |
649 | ||
650 | <a name="method4"></a> | |
651 | <p/><strong>int MergingHooks::nMaxJets() </strong> <br/> | |
652 | Return the maximum number of additional jets to be merged. | |
653 | ||
654 | ||
655 | <a name="method5"></a> | |
656 | <p/><strong>int MergingHooks::nHardOutPartons() </strong> <br/> | |
657 | Returns the number of outgoing partons in the hard core process. | |
658 | ||
659 | ||
660 | <a name="method6"></a> | |
661 | <p/><strong>int MergingHooks::nHardOutLeptons() </strong> <br/> | |
662 | Returns the number of outgoing leptons in the hard core process. | |
663 | ||
664 | ||
665 | <a name="method7"></a> | |
666 | <p/><strong>int MergingHooks::nHardInPartons() </strong> <br/> | |
667 | Returns the number of incoming partons in the hard core process. | |
668 | ||
669 | ||
670 | <a name="method8"></a> | |
671 | <p/><strong>int MergingHooks::nHardInLeptons() </strong> <br/> | |
672 | Returns the number of incoming leptons in the hard core process. | |
673 | ||
674 | ||
675 | <a name="method9"></a> | |
676 | <p/><strong>int MergingHooks::nResInCurrent() </strong> <br/> | |
677 | The number of resonances in the hard process reconstructed from the | |
678 | current event. If e.g. the ME configuration was | |
679 | <i>pp -> (w+->e+ve)(z -> mu+mu-)jj</i>, and the ME generator put | |
680 | both intermediate bosons into the LHE file, this will return 2. | |
681 | ||
682 | ||
683 | <a name="method10"></a> | |
684 | <p/><strong>double MergingHooks::tms() </strong> <br/> | |
685 | Returns the value used as the merging scale. | |
686 | ||
687 | ||
688 | <p/> Filling output histograms for the event then proceeds along the | |
689 | lines described above in "Histogramming the events". | |
690 | ||
691 | <p/> The full procedure is outlined in <code>main82.cc</code>. Special | |
692 | care needs to be taken when the output is stored in the form of HepMC | |
693 | files for RIVET usage. | |
694 | ||
695 | <h4>Defining a cut on lowest jet multiplicity events</h4> | |
696 | ||
697 | <p/> It can sometimes happen that when generating LHE files, a fairly | |
698 | restrictive cut has been used when generating the lowest multiplicity | |
699 | matrix element configurations. Then, it can happen that states that | |
700 | are (in the generation of a parton shower history) constructed by | |
701 | reclustering from higher multiplicity configurations, do not pass | |
702 | this matrix element cut. | |
703 | ||
704 | <p/> Consider as an example pure QCD dijet merging, when up to one | |
705 | additional jet should be merged. Three-jet matrix element | |
706 | configurations for which the reclustered two-jet state does not pass | |
707 | the cuts applied to the two-jet matrix element would never have been | |
708 | produced by showering the two-jet matrix element. This means that the | |
709 | three-jet matrix element includes regions of phase space that would | |
710 | never have been populated by the parton shower. Thus, since the | |
711 | matrix element phase space is larger than the shower phase space, | |
712 | merging scale dependencies are expected. A priori, this is not | |
713 | troublesome, since the aim of matrix element merging is to include | |
714 | regions of phase space outside the range of the parton shower | |
715 | approximation into the shower. An example is the inclusion of | |
716 | configurations with only unordered histories. | |
717 | ||
718 | <p/> Clearly, if the parton shower phase space is very constrained by | |
719 | applying stringent cuts to the two-jet matrix element, merging scale | |
720 | dependencies can become sizable, as was e.g. seen in [<a href="Bibliography.php" target="page">Lon11</a>] | |
721 | when forcing shower emissions to be ordered both in the evolution | |
722 | variable and in rapidity. To influence the effect of large phase | |
723 | space differences for shower emissions and matrix element | |
724 | configurations due to LHEF generation cuts, the user has to write a | |
725 | small piece of code overwriting method | |
726 | ||
727 | <a name="method11"></a> | |
728 | <p/><strong>virtual double MergingHooks::dampenIfFailCuts(const Event&event) </strong> <br/> | |
729 | multiplicity reclustered state as an input Event. From this input | |
730 | event, the user can then check if matrix element cuts are | |
731 | fulfilled. The return value will be internally multiplied to the | |
732 | CKKW-L weight of the current event. Thus, if the user wishes to | |
733 | suppress contributions not passing particular cuts, a number smaller | |
734 | than unity can be returned. | |
735 | ||
736 | ||
737 | <p/> Note that this method gives the user access to the lowest | |
738 | multiplicity state, which ( e.g. in the case of incomplete histories) | |
739 | does not have to be a <i>2 → 2</i> configuration. Also, changing the | |
740 | weight of the current event by hand is of course a major intervention | |
741 | in the algorithm, and should be considered very carefully. Generally, | |
742 | if this facility would have to be used extensively, it is certainly | |
743 | preferable to be less restrictive when applying additional, | |
744 | non-merging-scale-related cuts to the matrix element. | |
745 | ||
746 | <p/> An example how to force a cut on lowest multiplicity reclustered | |
747 | states for pure QCD matrix element configurations is given by | |
748 | <code>main83.cc</code> (to be used with e.g. <code>main82.cmnd</code>). | |
749 | ||
750 | <h4>Influencing the construction of all possible histories</h4> | |
751 | ||
752 | <p/> Even more powerful - and dangerous - is influencing the construction | |
753 | of histories directly. This should only be attempted by expert users. If you | |
754 | believe manipulations completely unavoidable, we advise you to take great care | |
755 | when redefining the following functions. | |
756 | ||
757 | <a name="method12"></a> | |
758 | <p/><strong>virtual bool MergingHooks::canCutOnRecState() </strong> <br/> | |
759 | In the base class this method returns false. If you redefine it | |
760 | to return true then the method <code>doCutOnRecState(...)</code> | |
761 | will be called for each reclustered state encountered in the generation of | |
762 | all possible histories of the matrix element state. | |
763 | ||
764 | ||
765 | <a name="method13"></a> | |
766 | <p/><strong>virtual bool MergingHooks::doCutOnRecState(const Event&event) </strong> <br/> | |
767 | This routine will be supplied internally with every possible reclustered | |
768 | event that can be reached by reclustering any number of partons in | |
769 | the matrix element input state. The new, reclustered, states can then be | |
770 | analysed. If the method returns false, the history to which the state belongs | |
771 | will be treated as if it were unordered, i.e. this path will only be chosen | |
772 | if no other histories are available. In this way, the number of histories | |
773 | not fulfilling the user criterion will be minimised. | |
774 | ||
775 | ||
776 | <p/> | |
777 | Clearly, these methods are highly intrusive. It could e.g. happen that no | |
778 | history is allowed, which would make merging impossible. One example where | |
779 | this method could be useful is if cuts on the core <i>2 -> 2</i> processes | |
780 | have to be checked, and the method | |
781 | <code>MergingHooks::dampenIfFailCuts(const Event& event)</code> is not | |
782 | sufficiently effective. | |
783 | ||
784 | ||
785 | <br/><br/><hr/> | |
786 | <h3>Matrix element merging and HepMC output for RIVET</h3> | |
787 | ||
788 | An example how to produce matrix element merged events to be analysed | |
789 | with RIVET is given by <code>main84.cc</code>. | |
790 | ||
791 | <p/> The main issue is that the output of separate RIVET runs can not | |
792 | in general be combined. To perform a matrix element merging, we | |
793 | however need to runs over different LHE files. The solution to this | |
794 | problem (so far) is to only perform one RIVET run for all matrix | |
795 | elements, i.e. print the events for all ME parton multiplicities, | |
796 | with the correct weights, to a single HepMC file. Since the correct | |
797 | weight includes the cross section of the different samples after | |
798 | Sudakov vetoes --- which is not a priori known --- the cross sections | |
799 | have to be estimated in a test run, before the actual production run | |
800 | is performed. Finally, the cross section of the last event in the | |
801 | HepMC file has to be taken as the full merged cross section | |
802 | <i>sigma_merge = Sum_{i=0}^N Sum_{j=0}*^{nEvents} | |
803 | sigma_est(i)*wckkwl(j)</i>. | |
804 | ||
805 | <p/> This procedure is outlined in <code>main84.cc</code>. | |
806 | ||
807 | <br/><br/><hr/> | |
808 | <h3>Further variables</h3> | |
809 | ||
810 | For more advanced manipulations of the merging machinery, all | |
811 | parameter changes that were investigated in [<a href="Bibliography.php" target="page">Lon11</a>] are | |
812 | supplied. Please check [<a href="Bibliography.php" target="page">Lon11</a>] for a detailed discussion of | |
813 | the switches. | |
814 | ||
815 | <p/> These switches allow enthusiastic users to perform a systematic | |
816 | assessment of the merging prescription. Apart from this, we advise the | |
817 | non-expert user to keep the default values. | |
818 | ||
819 | <br/><br/><strong>Merging:includeMassive</strong> <input type="radio" name="14" value="on" checked="checked"><strong>On</strong> | |
820 | <input type="radio" name="14" value="off"><strong>Off</strong> | |
821 | (<code>default = <strong>on</strong></code>)<br/> | |
822 | If on, use the correct massive evolution variable and massive | |
823 | splitting kernels in the reconstruction and picking of parton shower | |
824 | histories of the matrix element. If off, reconstruct evolution | |
825 | scales, kinematics and splitting kernels as if all partons were | |
826 | massless. | |
827 | ||
828 | ||
829 | <br/><br/><strong>Merging:enforceStrongOrdering</strong> <input type="radio" name="15" value="on"><strong>On</strong> | |
830 | <input type="radio" name="15" value="off" checked="checked"><strong>Off</strong> | |
831 | (<code>default = <strong>off</strong></code>)<br/> | |
832 | If on, preferably pick parton shower histories of the matrix element | |
833 | which have strongly ordered consecutive splittings, i.e. paths in | |
834 | which consecutive reclustered evolution scales are separated by a | |
835 | user-defined factor. | |
836 | ||
837 | ||
838 | <br/><br/><table><tr><td><strong>Merging:scaleSeparationFactor </td><td></td><td> <input type="text" name="16" value="1.0" size="20"/> (<code>default = <strong>1.0</strong></code>; <code>minimum = 1.0</code>; <code>maximum = 10.0</code>)</td></tr></table> | |
839 | The factor by which scales should differ to be classified as strongly | |
840 | ordered. | |
841 | ||
842 | ||
843 | <br/><br/><strong>Merging:orderInRapidity</strong> <input type="radio" name="17" value="on"><strong>On</strong> | |
844 | <input type="radio" name="17" value="off" checked="checked"><strong>Off</strong> | |
845 | (<code>default = <strong>off</strong></code>)<br/> | |
846 | If on, preferably pick parton shower histories of the matrix element | |
847 | with consecutive splittings ordered in rapidity and <i>pT</i>. | |
848 | ||
849 | ||
850 | <br/><br/><strong>Merging:pickByFullP</strong> <input type="radio" name="18" value="on" checked="checked"><strong>On</strong> | |
851 | <input type="radio" name="18" value="off"><strong>Off</strong> | |
852 | (<code>default = <strong>on</strong></code>)<br/> | |
853 | If on, pick parton shower histories of the matrix element by the full | |
854 | shower splitting kernels, including potential ME corrections and | |
855 | Jacobians from joined evolution measures. | |
856 | ||
857 | ||
858 | <br/><br/><strong>Merging:pickByPoPT2</strong> <input type="radio" name="19" value="on"><strong>On</strong> | |
859 | <input type="radio" name="19" value="off" checked="checked"><strong>Off</strong> | |
860 | (<code>default = <strong>off</strong></code>)<br/> | |
861 | If on, pick parton shower histories of the matrix element by the | |
862 | shower splitting kernels divided by the evolution <i>pT</i>. | |
863 | ||
864 | ||
865 | <br/><br/><strong>Merging:pickBySumPT</strong> <input type="radio" name="20" value="on"><strong>On</strong> | |
866 | <input type="radio" name="20" value="off" checked="checked"><strong>Off</strong> | |
867 | (<code>default = <strong>off</strong></code>)<br/> | |
868 | If on, exclusively pick parton shower histories of the matrix element | |
869 | for which have the smallest sum of scalar evolution <i>pT</i> for consecutive | |
870 | splittings has been calculated. | |
871 | ||
872 | ||
873 | <br/><br/><strong>Merging:includeRedundant</strong> <input type="radio" name="21" value="on"><strong>On</strong> | |
874 | <input type="radio" name="21" value="off" checked="checked"><strong>Off</strong> | |
875 | (<code>default = <strong>off</strong></code>)<br/> | |
876 | If on, then also include PDF ratios and <i>α<sub>s</sub></i> | |
877 | factors in the splitting probabilities used for picking a parton shower | |
878 | history of the matrix element, when picking histories by the full shower | |
879 | splitting probability. As argued in [<a href="Bibliography.php" target="page">Lon11</a>], this should not | |
880 | be done since a reweighting with PDF ratios and <i>α<sub>s</sub></i> | |
881 | factors will be performed. However, it can give useful insight in how | |
882 | sensitive the results are to the prescription on how to choose PS | |
883 | histories. | |
884 | ||
885 | ||
886 | <br/><br/><table><tr><td><strong>Merging:nonJoinedNorm </td><td></td><td> <input type="text" name="22" value="1.0" size="20"/> (<code>default = <strong>1.0</strong></code>; <code>minimum = 0.0</code>; <code>maximum = 10.0</code>)</td></tr></table> | |
887 | Normalisation factor with which to multiply splitting probability for | |
888 | splittings without joined evolution equation. | |
889 | ||
890 | ||
891 | <br/><br/><table><tr><td><strong>Merging:fsrInRecNorm </td><td></td><td> <input type="text" name="23" value="1.0" size="20"/> (<code>default = <strong>1.0</strong></code>; <code>minimum = 0.0</code>; <code>maximum = 10.0</code>)</td></tr></table> | |
892 | Normalisation factor with which to multiply splitting probability for | |
893 | final state splittings with an initial state recoiler. | |
894 | ||
895 | ||
896 | <br/><br/><table><tr><td><strong>Merging:aCollFSR </td><td></td><td> <input type="text" name="24" value="1.0" size="20"/> (<code>default = <strong>1.0</strong></code>; <code>minimum = 0.0</code>; <code>maximum = 10.0</code>)</td></tr></table> | |
897 | Factor with which to multiply the scalar <i>pT</i> of a final state | |
898 | splitting, when choosing the history by the smallest sum of scalar | |
899 | <i>pT</i>. Default value taken from Herwig++ [<a href="Bibliography.php" target="page">Tul09</a>]. | |
900 | ||
901 | ||
902 | <br/><br/><table><tr><td><strong>Merging:aCollISR </td><td></td><td> <input type="text" name="25" value="0.9" size="20"/> (<code>default = <strong>0.9</strong></code>; <code>minimum = 0.0</code>; <code>maximum = 10.0</code>)</td></tr></table> | |
903 | Factor with which to multiply the scalar <i>pT</i> of an initial state | |
904 | splitting, when choosing the history by the smallest sum of scalar | |
905 | <i>pT</i>. Default value taken from Herwig++ [<a href="Bibliography.php" target="page">Tul09</a>]. | |
906 | ||
907 | ||
908 | <br/><br/><table><tr><td><strong>Merging:unorderedScalePrescrip </td><td> (<code>default = <strong>0</strong></code>; <code>minimum = 0</code>; <code>maximum = 1</code>)</td></tr></table> | |
909 | When the parton shower history of the matrix element contains a | |
910 | sequence of splittings which are not ordered in evolution <ei>pT</ei> | |
911 | (called an unordered history), this sequence is interpreted as a combined | |
912 | emission. Then, a decision on which starting scale for trial emissions | |
913 | off reconstructed states in this sequence of unordered splittings has | |
914 | to be made. Two options are available: | |
915 | <br/> | |
916 | <input type="radio" name="26" value="0" checked="checked"><strong>0 </strong>: Use larger of the two reconstructed (unordered) scales as starting scale. <br/> | |
917 | <input type="radio" name="26" value="1"><strong>1 </strong>: Use smaller of the two reconstructed (unordered) scales as starting scale. <br/> | |
918 | ||
919 | <br/><br/><table><tr><td><strong>Merging:unorderedASscalePrescrip </td><td> (<code>default = <strong>1</strong></code>; <code>minimum = 0</code>; <code>maximum = 1</code>)</td></tr></table> | |
920 | Prescription which scale to use to evaluate <ei>α<sub>s</sub></ei> | |
921 | weight for splittings in a sequence of splittings which are not ordered | |
922 | in evolution <ei>pT</ei>. | |
923 | <br/> | |
924 | <input type="radio" name="27" value="0"><strong>0 </strong>: Use the combined splitting scale as argument in <ei>α<sub>s</sub></ei>, for both splittings. <br/> | |
925 | <input type="radio" name="27" value="1" checked="checked"><strong>1 </strong>: Use the true reconstructed scale as as argument in <ei>α<sub>s</sub></ei>, for each splitting separately. <br/> | |
926 | ||
927 | <br/><br/><table><tr><td><strong>Merging:unorderedPDFscalePrescrip </td><td> (<code>default = <strong>0</strong></code>; <code>minimum = 0</code>; <code>maximum = 1</code>)</td></tr></table> | |
928 | Prescription which scale to use to evaluate ratios of parton distibutions | |
929 | for splittings in a sequence of splittings which are not ordered | |
930 | in evolution <ei>pT</ei>. | |
931 | <br/> | |
932 | <input type="radio" name="28" value="0" checked="checked"><strong>0 </strong>: Use the combined splitting scale as argument in PDF ratios, for both splittings. <br/> | |
933 | <input type="radio" name="28" value="1"><strong>1 </strong>: Use the true reconstructed scale as argument in PDF ratios, for each splitting separately. <br/> | |
934 | ||
935 | <br/><br/><table><tr><td><strong>Merging:incompleteScalePrescrip </td><td> (<code>default = <strong>0</strong></code>; <code>minimum = 0</code>; <code>maximum = 2</code>)</td></tr></table> | |
936 | When no complete parton shower history (i.e. starting from a | |
937 | <ei>2 → 2</ei> process) for a matrix element with additional jets | |
938 | can be found, such a configuration is said to have an incomplete history. | |
939 | Since in incomplete histories, not all shower starting scales are | |
940 | determined by clusterings, a prescription for setting the starting scale | |
941 | of trial showers in incomplete histories is needed. Three options are | |
942 | provided. | |
943 | <br/> | |
944 | <input type="radio" name="29" value="0" checked="checked"><strong>0 </strong>: Use factorisation scale as shower starting scale for incomplete histories. <br/> | |
945 | <input type="radio" name="29" value="1"><strong>1 </strong>: Use <ei>sHat</ei> as shower starting scale for incomplete histories. <br/> | |
946 | <input type="radio" name="29" value="2"><strong>2 </strong>: Use <ei>s</ei> as shower starting scale for incomplete histories. <br/> | |
947 | ||
948 | <br/><br/><strong>Merging:allowColourShuffling</strong> <input type="radio" name="30" value="on"><strong>On</strong> | |
949 | <input type="radio" name="30" value="off" checked="checked"><strong>Off</strong> | |
950 | (<code>default = <strong>off</strong></code>)<br/> | |
951 | If on, this will allow the algorithm to swap one colour index in the state, | |
952 | when trying to find all possible clusterings, if no clustering has been | |
953 | found, but more clusterings had been requested. In this way, some incomplete | |
954 | histories can be avoided. Generally, we advise the non-expert user to not | |
955 | touch this switch, because a slight change in the colour structure can change | |
956 | the radiation pattern. To however study the sensitivity of the predictions on | |
957 | these effects, allowing for colour reshuffling can be useful. | |
958 | ||
959 | ||
960 | <br/><br/><strong>Merging:usePythiaQRenHard</strong> <input type="radio" name="31" value="on" checked="checked"><strong>On</strong> | |
961 | <input type="radio" name="31" value="off"><strong>Off</strong> | |
962 | (<code>default = <strong>on</strong></code>)<br/> | |
963 | If on, this will allow the algorithm to use a dynamical renormalisation scale | |
964 | to evaluate the strong couplings of the core hard process in dijet and | |
965 | prompt photon events. | |
966 | This means that the value of <i>α<sub>s</sub></i> used as coupling | |
967 | of the hard process in the matrix element generation will be replaced with | |
968 | a running coupling evaluated at the geometric mean of the squared transverse | |
969 | masses of the two outgoing particles, as is the default prescription in | |
970 | Pythia. | |
971 | ||
972 | ||
973 | <br/><br/><strong>Merging:usePythiaQFacHard</strong> <input type="radio" name="32" value="on" checked="checked"><strong>On</strong> | |
974 | <input type="radio" name="32" value="off"><strong>Off</strong> | |
975 | (<code>default = <strong>on</strong></code>)<br/> | |
976 | If on, this will allow the algorithm to use a dynamical factorisation scale | |
977 | to evaluate parton distributions associated with the hadronic cross section | |
978 | of the core hard process in dijet and prompt photon events. | |
979 | In the calculation of PDF ratios as part of the CKKW-L weight of an event, | |
980 | parton distributions that should be evaluated at the scale of the core | |
981 | 2 - >2 process will be evaluated using the dynamical factorisation scale | |
982 | Pythia would attribute to this process. This means that the hard process | |
983 | factorisation scale is set to the smaller of the squared transverse masses | |
984 | of the two outgoing particles. | |
985 | ||
986 | ||
987 | <input type="hidden" name="saved" value="1"/> | |
988 | ||
989 | <?php | |
990 | echo "<input type='hidden' name='filepath' value='".$_GET["filepath"]."'/>"?> | |
991 | ||
992 | <table width="100%"><tr><td align="right"><input type="submit" value="Save Settings" /></td></tr></table> | |
993 | </form> | |
994 | ||
995 | <?php | |
996 | ||
997 | if($_POST["saved"] == 1) | |
998 | { | |
999 | $filepath = $_POST["filepath"]; | |
1000 | $handle = fopen($filepath, 'a'); | |
1001 | ||
1002 | if($_POST["1"] != "off") | |
1003 | { | |
1004 | $data = "Merging:doKTMerging = ".$_POST["1"]."\n"; | |
1005 | fwrite($handle,$data); | |
1006 | } | |
1007 | if($_POST["2"] != "1") | |
1008 | { | |
1009 | $data = "Merging:ktType = ".$_POST["2"]."\n"; | |
1010 | fwrite($handle,$data); | |
1011 | } | |
1012 | if($_POST["3"] != "0") | |
1013 | { | |
1014 | $data = "Merging:nJetMax = ".$_POST["3"]."\n"; | |
1015 | fwrite($handle,$data); | |
1016 | } | |
1017 | if($_POST["4"] != "0.0") | |
1018 | { | |
1019 | $data = "Merging:TMS = ".$_POST["4"]."\n"; | |
1020 | fwrite($handle,$data); | |
1021 | } | |
1022 | if($_POST["5"] != "void") | |
1023 | { | |
1024 | $data = "Merging:Process = ".$_POST["5"]."\n"; | |
1025 | fwrite($handle,$data); | |
1026 | } | |
1027 | if($_POST["6"] != "off") | |
1028 | { | |
1029 | $data = "Merging:doMGMerging = ".$_POST["6"]."\n"; | |
1030 | fwrite($handle,$data); | |
1031 | } | |
1032 | if($_POST["7"] != "off") | |
1033 | { | |
1034 | $data = "Merging:doPTLundMerging = ".$_POST["7"]."\n"; | |
1035 | fwrite($handle,$data); | |
1036 | } | |
1037 | if($_POST["8"] != "off") | |
1038 | { | |
1039 | $data = "Merging:doCutBasedMerging = ".$_POST["8"]."\n"; | |
1040 | fwrite($handle,$data); | |
1041 | } | |
1042 | if($_POST["9"] != "0.0") | |
1043 | { | |
1044 | $data = "Merging:QijMS = ".$_POST["9"]."\n"; | |
1045 | fwrite($handle,$data); | |
1046 | } | |
1047 | if($_POST["10"] != "0.0") | |
1048 | { | |
1049 | $data = "Merging:pTiMS = ".$_POST["10"]."\n"; | |
1050 | fwrite($handle,$data); | |
1051 | } | |
1052 | if($_POST["11"] != "0.0") | |
1053 | { | |
1054 | $data = "Merging:dRijMS = ".$_POST["11"]."\n"; | |
1055 | fwrite($handle,$data); | |
1056 | } | |
1057 | if($_POST["12"] != "on") | |
1058 | { | |
1059 | $data = "Merging:enforceCutOnLHE = ".$_POST["12"]."\n"; | |
1060 | fwrite($handle,$data); | |
1061 | } | |
1062 | if($_POST["13"] != "off") | |
1063 | { | |
1064 | $data = "Merging:doUserMerging = ".$_POST["13"]."\n"; | |
1065 | fwrite($handle,$data); | |
1066 | } | |
1067 | if($_POST["14"] != "on") | |
1068 | { | |
1069 | $data = "Merging:includeMassive = ".$_POST["14"]."\n"; | |
1070 | fwrite($handle,$data); | |
1071 | } | |
1072 | if($_POST["15"] != "off") | |
1073 | { | |
1074 | $data = "Merging:enforceStrongOrdering = ".$_POST["15"]."\n"; | |
1075 | fwrite($handle,$data); | |
1076 | } | |
1077 | if($_POST["16"] != "1.0") | |
1078 | { | |
1079 | $data = "Merging:scaleSeparationFactor = ".$_POST["16"]."\n"; | |
1080 | fwrite($handle,$data); | |
1081 | } | |
1082 | if($_POST["17"] != "off") | |
1083 | { | |
1084 | $data = "Merging:orderInRapidity = ".$_POST["17"]."\n"; | |
1085 | fwrite($handle,$data); | |
1086 | } | |
1087 | if($_POST["18"] != "on") | |
1088 | { | |
1089 | $data = "Merging:pickByFullP = ".$_POST["18"]."\n"; | |
1090 | fwrite($handle,$data); | |
1091 | } | |
1092 | if($_POST["19"] != "off") | |
1093 | { | |
1094 | $data = "Merging:pickByPoPT2 = ".$_POST["19"]."\n"; | |
1095 | fwrite($handle,$data); | |
1096 | } | |
1097 | if($_POST["20"] != "off") | |
1098 | { | |
1099 | $data = "Merging:pickBySumPT = ".$_POST["20"]."\n"; | |
1100 | fwrite($handle,$data); | |
1101 | } | |
1102 | if($_POST["21"] != "off") | |
1103 | { | |
1104 | $data = "Merging:includeRedundant = ".$_POST["21"]."\n"; | |
1105 | fwrite($handle,$data); | |
1106 | } | |
1107 | if($_POST["22"] != "1.0") | |
1108 | { | |
1109 | $data = "Merging:nonJoinedNorm = ".$_POST["22"]."\n"; | |
1110 | fwrite($handle,$data); | |
1111 | } | |
1112 | if($_POST["23"] != "1.0") | |
1113 | { | |
1114 | $data = "Merging:fsrInRecNorm = ".$_POST["23"]."\n"; | |
1115 | fwrite($handle,$data); | |
1116 | } | |
1117 | if($_POST["24"] != "1.0") | |
1118 | { | |
1119 | $data = "Merging:aCollFSR = ".$_POST["24"]."\n"; | |
1120 | fwrite($handle,$data); | |
1121 | } | |
1122 | if($_POST["25"] != "0.9") | |
1123 | { | |
1124 | $data = "Merging:aCollISR = ".$_POST["25"]."\n"; | |
1125 | fwrite($handle,$data); | |
1126 | } | |
1127 | if($_POST["26"] != "0") | |
1128 | { | |
1129 | $data = "Merging:unorderedScalePrescrip = ".$_POST["26"]."\n"; | |
1130 | fwrite($handle,$data); | |
1131 | } | |
1132 | if($_POST["27"] != "1") | |
1133 | { | |
1134 | $data = "Merging:unorderedASscalePrescrip = ".$_POST["27"]."\n"; | |
1135 | fwrite($handle,$data); | |
1136 | } | |
1137 | if($_POST["28"] != "0") | |
1138 | { | |
1139 | $data = "Merging:unorderedPDFscalePrescrip = ".$_POST["28"]."\n"; | |
1140 | fwrite($handle,$data); | |
1141 | } | |
1142 | if($_POST["29"] != "0") | |
1143 | { | |
1144 | $data = "Merging:incompleteScalePrescrip = ".$_POST["29"]."\n"; | |
1145 | fwrite($handle,$data); | |
1146 | } | |
1147 | if($_POST["30"] != "off") | |
1148 | { | |
1149 | $data = "Merging:allowColourShuffling = ".$_POST["30"]."\n"; | |
1150 | fwrite($handle,$data); | |
1151 | } | |
1152 | if($_POST["31"] != "on") | |
1153 | { | |
1154 | $data = "Merging:usePythiaQRenHard = ".$_POST["31"]."\n"; | |
1155 | fwrite($handle,$data); | |
1156 | } | |
1157 | if($_POST["32"] != "on") | |
1158 | { | |
1159 | $data = "Merging:usePythiaQFacHard = ".$_POST["32"]."\n"; | |
1160 | fwrite($handle,$data); | |
1161 | } | |
1162 | fclose($handle); | |
1163 | } | |
1164 | ||
1165 | ?> | |
1166 | </body> | |
1167 | </html> | |
1168 | ||
1169 | <!-- Copyright (C) 2012 Torbjorn Sjostrand --> |