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 --> |
---|