+++ /dev/null
-
-<chapter name="Matrix Element Merging">
-
-<h2>Matrix Element Merging</h2>
-
-CKKW-L merging <ref>Lon01</ref> allows for a consistent merging of parton
-showers with
-matrix elements to include multiple well-separated partons. The
-algorithm implemented in PYTHIA is described in <ref>Lon11</ref>. To
-perform matrix element merging, the user has to supply LHE
-files <ref>Alw07</ref> for the hard process and the corresponding
-process with up to N additional jets.
-
-<p/> The usage of the merging procedure is illustrated in a few
-example main programs
-(<code>main81.cc</code>, <code>main82.cc</code>,
-<code>main83.cc</code> and <code>main84.cc</code>, together with the
-input files <code>main81.cmnd</code>, <code>main82.cmnd</code> and
-<code>main84.cmnd</code>). These examples should of course only serve
-as an illustration, and as such will not make use of the merging in
-all possible ways. For full generality, the example programs link to
-LHAPDF, FastJet and HepMC. Of course the user is welcome to remove
-these dependencies. To remove the FastJet dependence, the functions
-calculating example observables have to be deleted. Removing the
-LHAPDF dependence requires changing the cmnd input files to choose an
-inbuilt PDF, as outlined in the
-<a href="PDFSelection.html" target="page">PDF documentation</a>. The
-HepMC dependence can be removed by erasing the code allowing for HepMC
-output.
-
-<p/> Please note that a detailed tutorial on merging in Pythia is available
-from
-<strong>http://home.thep.lu.se/~torbjorn/pythia8/mergingworksheet8160.pdf
-</strong>
-
-<p/> Three very short LHE files (<code>w+_production_lhc_0.lhe</code>,
-<code>w+_production_lhc_1.lhe</code>, <code>w+_production_lhc_2.lhe</code>)
-are included in the distribution. These files are not intended for
-physics studies, but only serve as input for the example main
-programs. For realistic studies, the user has to supply LHE files.
-
-<p/> In the generation of LHE files, the value of the factorisation
-scale used in the PDFs is not important, since the cross section will
-be multiplied by ratios of PDFs to adjust to the PYTHIA starting
-scales. The same is true for the renormalisation scale (and starting
-value <ei>α<sub>s</sub>(M<sub>Z</sub>)</ei>) used to evaluate
-<ei>α<sub>s</sub></ei>. Coupling and scale choices by the user
-will be transferred to the merging routines.
-
-<p/> Multi-jet events can suffer from infrared divergences in the
-calculation. Sensible matrix element generator (MEG) outputs should not
-contain phase space points in which the calculation is ill-defined, meaning
-infrared regions need to be removed by cuts. This is most conveniently done
-by disallowing the MEG to produce partons below a
-minimal parton-parton separation in a certain jet algorithm. Using
-dedicated cuts to regularise MEG output is of course possible as well. Any
-regularisation criterion defines the matrix element region: The parts of
-phase space in which the fixed order calculation is considered valid and
-preferable to the parton shower. Matrix element merging is combining
-MEG events in the matrix element region with parton shower events in regions
-outside the regularisation cut (often called parton shower region). Because
-the regularisation cut defines a boundary between the matrix element
-and parton shower regions, i.e. the regions to be merged into one inclusive
-sample, it is usually called <ei> merging scale </ei>. Since many different
-cut choices may regularise the MEG calculation, many different merging scale
-definitions are possible. A few standard choices are listed below, as well as
-documentation on how to use a user-defined cut criterion. In combining matrix
-element and parton shower regions, the CKKW-L prescription tries to minimise
-the dependence on the merging scale. This can only be achieved if the
-combination of MEG events and parton shower populates the whole phase space.
-Additional cuts on the partons in the LHEF generation should hence be
-avoided as much as possible, meaning that the merging scale cut should always
-pose a more stringent cut than all other cuts on the partons. Of course, if
-the hard process itself is divergent, cuts need to be made. However, this
-should be chosen in such a way as to not exclude regions that will be
-available to the matrix elements with additional jets. An example is QCD
-di-jet production with additional jets: Say the <ei>2 -> 2</ei> process is
-regularised with a <ei>pTmin</ei> cut of pTminCut = 100 GeV, and
-the <ei>2 - >3</ei> sample is regularised with a <ei>kTmin</ei>-cut of
-kTminCut = 50 GeV. This would mean that when reclustering
-the emission in the 2 -> 3 sample, we could end up with a
-pT value <ei>pTminNow</ei> of the 2 -> 2 configuration with
-<ei>pTminCut > pTminNow</ei>, which is excluded in the
-2 -> 2 sample. Thus, the 2 -> 3 sample will include a
-Sudakov factor not included in the 2 -> 2 sample, resulting
-in merging scale dependencies. Such dependencies can be avoided if
-the additional cuts on the hard process are minimal.
-
-<p/> Of course, additional cuts on electroweak particles are
-allowed. These should be the same for all samples with
- <ei>0 <= n <= N</ei> additional partons.
-
-<p/> If it is not possible to generate LHE files with minimal cuts,
-the user can choose to use the <code>MergingHooks</code> structures in
-order to decide how much influence to attribute to parton shower
-histories in which the reclustered lowest multiplicity process does
-not pass the matrix element cuts. This is described below.
-
-<p/> When generating LHE files, we advise against putting
-unstable particles (e.g. massive gauge bosons) in the final state.
-Rather, specify a resonance by its decay products, e.g. if Les Houches
-events for the <ei>pp → Z + jets → e+e- + jets</ei> process
-are desired, generate the matrix element events with the <ei>Z</ei> decay
-included. From a physical point of view, on-shell final massive gauge
-bosons should not be considered part of a hard process, since only
-the boson decay products will be detectable. Furthermore,
-non-narrow-width approximation contributions are not present if the
-ME generator only produces on-shell bosons. Interference effects
-between different production channels for the decay products would
-also be neglected. These points seem an unnecessary restriction on
-the accuracy of the ME calculation. In addition, there is a
-technical reason for this strategy. Since some matrix element
-generators choose to put additional information on intermediate
-bosons into Les Houches events, depending on if they pass a certain
-criterion (e.g. being close to the mass shell), without exact
-knowledge of this criterion, the only feasible way of bookkeeping the
-hard process is by identifying outgoing decay products.
-
-<p/> Despite these considerations, (massive) gauge bosons in the final state
-are allowed in the hard process definition. This is useful particularly for
-Higgs physics, when different decays of the Higgs boson need to be simulated
-after the LHEF generation.
-
-<p/> For all merging purposes, processes with different charge of
-outgoing leptons are considered different processes. That means
-e.g. that <ei>e+ν<sub>e</sub>+ jets</ei> and
-<ei>e-ν̄<sub>e</sub> + jets</ei>
-are considered independent processes. If the user wishes to generate
-distributions including effects of more than one process, merged
-samples for all independent processes should be generated separately
-and added afterwards. Alternatively, to combine simple processes,
-combined LHE files can be used in conjunction with flexible containers (see
-below).
-
-<p/> When the matrix element merging is used to produce HepMC
-<ref>Dob01</ref> files to be analysed with RIVET <ref>Buc10</ref>,
-special care needs to taken in how the cross section is read by RIVET
-(see below).
-
-<p/> To specify the merging conditions, additionally information on
-the merging scale value and the functional definition of the merging
-scale is needed. A few standard definitions of merging scales are
-available. We hope this makes the user interface less cumbersome.
-
-<p/> Different choices intrinsic to the CKKW-L merging procedure might
-be relevant for the user as well. The base
-class <code>MergingHooks</code> gives the user the opportunity to
-define the functional form of the merging scale. In the following,
-the usage of the merging machinery to consistently include LHE files
-with additional jets into PYTHIA will be discussed.
-
-<br/><br/><hr/>
-<h3>Merging scale definitions</h3>
-
-<p/> The quickest way to include processes with additional jets is to
-produce LHE files with one of the standard ways to define the merging
-scale. Three standard ways to define a merging scale (minimal <ei>kT</ei>,
-minimal evolution <ei>pT</ei> and by three cuts) are implemented. All of these
-prescriptions are equivalent - different definitions have only been introduced
-for the convenience of users, who might be limited by which cuts can be used
-in the generation of LHE files. Below, we describe how to switch on and use
-these different merging scale definitions.
-
-<h4>Merging with merging scale defined in kT:</h4>
-
-<flag name="Merging:doKTMerging" default="off">
-If the additional jets in the LHE files have been regulated by
-a <ei>kT</ei> cut, the user can supply the merging scale definition by
-setting this flag to on. <ei>kT</ei> here and below means cutting on
-Durham <ei>kT</ei> for <ei>e+e-</ei> collisions, and cutting on
-longitudinally invariant <ei>kT</ei> for hadronic collisions. Please note
-that this particular merging scale definition will check <ei>kT</ei> between
-all pairs of <ei>u,d,c,s,b,g</ei> partons.
-</flag>
-
-</p>
-Currently, the name longitudinally invariant <ei>kT</ei> is used
-for a few jet recombination algorithms with slightly different
-jet measures. A specific form can be chosen by setting the switch
-
-<modepick name="Merging:ktType" default="1" min="1" max="3">
-Precise functional definition of longitudinally
-invariant <ei>kT</ei>. For e+e- collisions, <ei>Durham kT</ei> is
-always defined by the square root of <ei>min{ 2*min[ </sub>
-E<sub>i</sub><sup>2</sup>, E<sub>j</sub><sup>2</sup>] * [ 1 -
-cosθ<sub>ij</sub>] }</ei>, so that this switch will have no effect.
-<option value="1"> 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.
-</option>
-<option value="2">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.
-</option>
-<option value="3"> 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.
-</option>
-</modepick>
-
-<modeopen name="Merging:nJetMax" default="0" min="0">
-Maximal number of additional jets in the matrix element
-</modeopen>
-
-<parm name="Merging:TMS" default="0.0">
-The value of the merging scale. The name is inspired by the scale in
-evolution equations, which is often called 't', and the suffix 'MS' stands
-for merging scale. In the particular case of <ei>kT</ei>-merging, this
-would be the value of the <ei>kT</ei>-cut in GeV. For any merging scale
-definition, this input is considered the actual value of the merging
-scale.
-</parm>
-
-<word name="Merging:Process" default="void">
-The string specifying the hard core process, in MG4/ME notation.
-</word>
-
-</p>
-If e.g. <ei>W + jets</ei> merging should be performed, set this to
-<code>pp>e+ve</code> (<i>without white spaces or quotation marks</i>).
-This string may contain resonances in the MG/ME notation, e.g. for merging
-<ei>pp→Z W<sup>+</sup>→q q̄ e+ν<sub>e</sub> + jets</ei>,
-the string <code>pp>(z>jj)(w+>e+ve)</code> would be applicable.
-
-<p/>
-A lot more flexible hard process definitions are possible. To not dwell too
-much on these details here, we will come back to the process string at the end
-of this section.
-
-
-<flag name="Merging:doMGMerging" default="off">
-Even easier, but highly non-general, is to perform the merging with
-MadGraph/MadEvent-produced LHE files, with a merging scale defined by
-a <ei>kT</ei> cut. For this, set this switch to on. The merging scale
-value will be read from the +1 jet LHE file by searching for the
-string <code>ktdurham</code>, and extracting the value from <code>
-value = ktdurham</code>. Also, the hard process will be read from
-the +0 jet LHE file, from the line containing the string <code>@1</code>
-(the tag specifying the first process in the MadGraph process card).
-For this to work, PYTHIA should be initialised on LHE files called
-<code>NameOfYourLesHouchesFile_0.lhe</code> (+0 jet sample) and
-<code>NameOfYourLesHouchesFile_1.lhe</code> (+1 jet sample) and the
-same naming convention for LHE files with two or more additional jets.
-Since for this option, the merging scale value is read from the
-LHEF, no merging scale value needs to be supplied by setting <code>
-Merging:TMS </code>. Also, the hard process is read from LHEF, the
-input <code>Merging::Process</code> does not have to be defined.
-However, the maximal number of merged jets still has to be supplied by
-setting <code>Merging:nJetMax</code>.
-</flag>
-
-
-<h4>Merging with merging scale defined in Pythia evolution pT:</h4>
-
-If the LHE file has been regularised by cutting on the minimal Pythia evolution
-pT in the state, this can also be used as a merging scale right away. For this,
-change the switch
-
-<flag name="Merging:doPTLundMerging" default="off">
-The merging scale is then defined by finding the minimal Pythia evolution pT
-between sets of radiator, emitted an recoiler partons. For this
-particular merging scale definition, <ei>u,d,c,s,b,g</ei> are considered
-partons. The Pythia evolution pT of a single three-parton set is defined by
-<p/>
-<ei>pT<sub>evol</sub> = z<sub>ijk</sub>(1-z<sub>ijk</sub>)
- Q<sub>ij</sub><sup>2</sup></ei> for FSR, where <ei>i</ei> is the radiating
- parton, <ei>j</ei> is the emitted parton and <ei>k</ei> is the recoiler, and
- <ei> Q<sub>ij</sub><sup>2</sup> =
- (p<sub>i</sub> + p<sub>j</sub>)<sup>2</sup> </ei>, and
- <ei>z<sub>ijk</sub> =
- x<sub>i,jk</sub> / (x<sub>i,jk</sub> + x<sub>j,ik</sub>)</ei> with
- <ei>x<sub>i,jk</sub> =
- 2 p<sub>i</sub> (p<sub>i</sub> + p<sub>j</sub> + p<sub>k</sub>)
- / (p<sub>i</sub> + p<sub>j</sub> + p<sub>k</sub>)<sup>2</sup> </ei>
-<p/>
-<ei>pT<sub>evol</sub> = (1-z<sub>ijk</sub>)
- Q<sub>ij</sub><sup>2</sup></ei> for ISR, where <ei>i</ei> is the radiating
- parton, <ei>j</ei> is the emitted parton and <ei>k</ei> is the second initial
- state parton, and
- <ei> Q<sub>ij</sub><sup>2</sup> =
- -(p<sub>i</sub> - p<sub>j</sub>)<sup>2</sup> </ei>, and
- <ei>z<sub>ijk</sub> =
- (p<sub>i</sub> - p<sub>j</sub> + p<sub>k</sub>)<sup>2</sup>
- / (p<sub>i</sub> + p<sub>k</sub>)<sup>2</sup> </ei>.
-
-<p/>
-When using this option, the merging scale is defined by the minimum
-<ei>pT<sub>evol</sub></ei> for all combinations of three partons in the event,
-irrespectively of flavour or colour-connections. The merging scale value will
-be read from the <code>Merging:TMS</code> parameter, so that this needs to be
-set just as in the case of the <ei>kT</ei>-merging prescription. Of course you
-will also need to set <code>Merging:Process</code> and the maximal number of
-additional matrix element jets <code>Merging:nJetMax</code>.
-</flag>
-
-<h4>Merging with merging scale defined by a combination of cuts:</h4>
-
-It is possible to regularise QCD divergences in a LHE file by applying cuts
-to the kinematical pT of jets (<ei>pT<sub>i</sub></ei>), combined with a cut on
-<ei> ΔR<sub>ij</sub></ei> between jets and a cut on invariant mass
-<ei> Q<sub>ij</sub></ei> of jet pairs. The combination of these standard cuts
-can also serve as a merging scale. For this, use this setting
-
-<flag name="Merging:doCutBasedMerging" default="off">
-This switch will use cuts on (<ei>pT<sub>i</sub></ei>),
-<ei> ΔR<sub>ij</sub></ei> and
-<ei> Q<sub>ij</sub></ei> to define when parton shower emissions are allowed.
-Please note for this particular merging scale definition, only light jets
-(<ei>u,d,c,s,g</ei>) are checked.
-</flag>
-
-<p/>
-The values of the cuts will then be read from
-
-<parm name="Merging:QijMS" default="0.0">
-The value of the invariant mass cut <ei> Q<sub>ij</sub></ei> of pairs of final
-state partons used in the matrix element generation.
-</parm>
-
-<parm name="Merging:pTiMS" default="0.0">
-The value of the minimal transverse momentum cut <ei> pT<sub>i</sub></ei> on
-final state partons, as used in the matrix element generation.
-</parm>
-
-<parm name="Merging:dRijMS" default="0.0">
-The value of the minimal <ei> ΔR<sub>ij</sub></ei> separation between
-pairs of final state partons used in the matrix element generation, where
-<ei> ΔR<sub>ij</sub><sup>2</sup> = (Δy<sub>ij</sub>)<sup>2</sup> +
-(Δφ<sub>ij</sub>)<sup>2</sup></ei>.
-</parm>
-
-<p/>
-With knowledge of these values, and <code>Merging:doCutBasedMerging</code>,
-Pythia will use these cuts as a separation between matrix element phase space
-and parton shower region. If e.g. the Les Houches Events have been generated
-with the cuts <ei> ΔR<sub>ij</sub> = 0.1 </ei>,
-<ei>pT<sub>i</sub>= 20 GeV</ei> and <ei> Q<sub>ij</sub> = 40 GeV</ei>, set
-<code>Merging:QijMS=40.</code>,
-<code>Merging:pTjMS=20.</code>,
-<code>Merging:dRijMS=0.1</code> to perform a cut-based merging. Of course
-you will also need to set <code>Merging:Process</code> and the
-maximal number of additional matrix element jets
-<code>Merging:nJetMax</code>.
-
-<h4>Les Houches events outside the matrix element region</h4>
-
-</p>
-Before continuing, we would like to point out that in general, the user
-should make sure that the events in the Les Houches file are actually
-calculated using the regularisation cut definition and value(s) supplied to
-Pythia as merging scale definition and value(s). However, if LH files with
-a large number of events and loose merging scale cuts are available, it
-might be useful to choose a higher merging scale value, e.g. for merging
-scale variations as part of uncertainty assessments. If CKKW-L merging is
-enabled, Pythia will by default check if events read from Les Houches file
-are in the matrix element region as defined by the merging scale definition
-and merging scale value. Events outside the matrix element region will be
-discarded. To change this default behaviour, use the flag
-
-<flag name="Merging:enforceCutOnLHE" default="on">
-This will check if the events read from LHE file are in the matrix element
-region as defined by the merging scale definition and value(s). If on, LHE
-input outside the matrix element region will be rejected. If off, every
-event is assumed to pass the merging scale cut.
-</flag>
-
-<h4>Defining the hard process</h4>
-
-To perform CKKW-L matrix element merging, the user has to decide on a hard
-process, and communicate this choice to Pythia. This is done by setting the
-input <strong>Merging:Process</strong>
-
-<p/>
-For single processes in the Standard Model or the MSSM, MG4/ME notation is
-applicable. However, for some purposes, using a single simple process
-string is not satisfactory. Mixed W<sup>+</sup> and W<sup>-</sup> events
-in a single LHE file is a common example. For this case, it would of course
-be perfectly allowed to perform twice, once for W<sup>+</sup> production and
-once for W<sup>-</sup> production, and then add the results. Nevertheless, it
-seems reasonable to alleviate difficulties by allowing for less restrictive
-hard process definitions. Two generalisations of the process tag are
-available: Containers and user-defined particle tags. The syntax of these
-settings is described below.
-
-<p/>
-In case you want multiple processes in a LHE file to be treated on equal
-footing (e.g. <ei>W<sup>+</sup> + jets</ei> and <ei>W<sup>-</sup> + jets</ei>),
-you should use flexible containers do specify the hard process. So far, we
-allow the use of the containers <code>LEPTONS</code>, <code>NEUTRINOS</code>,
-<code>BQUARKS</code>. If you use these containers, the hard process definition
-is relatively flexible, meaning that Pythia will attempt a merging of QCD jets
-for each event in the LHE file, and assume that all particles matching one of
-the containers are products of the hard process. This is best explained by
-examples. If you want to have both <ei>pp → e+ ν<sub>e</sub> + jets</ei>
- and <ei>pp → e- ν̄<sub>e</sub> + jets</ei> events in a single
-file, you can set <code>Merging:Process=pp>LEPTONS,NEUTRINOS</code> as hard
-process (note that for readability, you are allowed to use commata to separate
-container names). Combining e.g. the processes
-<ei>pp → e+ ν<sub>e</sub></ei> and
-<ei>pp → μ+ ν<sub>μ</sub></ei> is possible with the hard process
-definition <code>pp>LEPTONS,NEUTRINOS</code>.
-
-<p/>
-For maximal flexibility, the definition of the hard process by these containers
-does not mean that each Les Houches event needs to contain particles to match
-each container. It is enough if one container is matched. This means that
-with the string <code>pp>LEPTONS,NEUTRINOS</code>, you can immediately process
-<ei>pp → e+ e- </ei> events mixed with
-<ei>pp → e+ ν<sub>e</sub></ei> events, since particles matching at
-least one container can be found in both cases. Another example for the usage
-of containers is mixing <ei>pp → e+ ν<sub>e</sub></ei> and
-<ei>pp → tt̄ → e+ ν<sub>e</sub> e- ν̄<sub>e</sub>
- bb̄</ei>. This can be accommodated by the hard process string
-<code>Merging:Process=pp>LEPTONS,NEUTRINOS,BQUARKS</code>.
-
-<p/>
-There is however a conceptual limitation to containers: The hard process
-definition is necessary to ensure that when constructing lower multiplicity
-states (that will be used to calculate the correct merging weight), the
-structure of the hard process will be preserved. If e.g. we want the hard process
-to be <ei>pp → Z → bb̄ </ei>, we should ensure that the lowest
-multiplicity state contains a colour-singlet bb̄-pair. When
-reconstructing intermediate lower multiplicity states from multi-jet matrix
-elements, we should thus always be able to find at least one bb̄-pair. By
-mixing different processes in a LHE file, this requirement might already be
-violated at the level of Les Houches events. Flexible containers cannot give
-strong conditions which flavours should be preserved in the construction of
-the hard process. In order to avoid non-sensible results, it is hence <ei>
-assumed that all</ei> particles matching any of the containers will be part
-of the lowest multiplicity process. This implies that if you decide to use the
-<code>BQUARKS</code> container, all b-quarks in the LHE file will be
-interpreted as hard process particles, and never as additional radiation.
-
-<p/>
-Another way to specify the hard process particles is to explicitly define the
-particle names and identifiers. This is necessary if the matrix element merging
-in Pythia does not contain the particles of interest. To make sure that the
-hard process is still treated correctly, it is possible to define particles
-in the process string. If you e.g. want the hard process to contain a particle
-"zeta~" with PDG identifier "12345", produced in proton collisions, you
-have to include a user-defined particle tag by setting the process string to
-<code>pp>{zeta~,12345}</code>. The user-defined particle is enclosed in
-curly brackets, with syntax
-<code>{particle_name,particle_identifier}</code>, where "particle_name"
-and "particle_identifier" are the particle name and particle identifier used
-for this particle in the input LHE file. User-defined particles are only
-allowed in the final state. You are free to fix user-defined particles with
-more common ones, as long as user-defined particles are put before more common
-particles in the process string. This means that if you e.g. wanted the hard
-process to contain a graviton in association with a positron and an
-electron-neutrino, you have to define the hard process as
-<code>pp>{G,39}e+ve</code>.
-
-<p/>
-Below you can find a list of particles predefined in the merging. If you wish
-to include a hard process with different final state particles, you may use
-the "curly bracket notation" outlined above.
-
-<p/>
-The set of incoming particles us limited to:
-<code>e-</code> (electron), <code>e+</code> (positron), <code>mu-</code> (muon),
-<code>mu+</code> (antimuon), <code>p</code> (proton, container to hold all
-initial state coloured particles), <code>p~</code> (identical to
-<code>p</code> container).
-
-<p/>
-The following intermediate particles are allowed:
-<code>a</code> (photon), <code>z</code> (Z boson),
-<code>w-</code> (W<sup>-</sup> boson), <code>w+</code> (W<sup>+</sup> boson),
-<code>h</code> (scalar Higgs boson), <code>W</code> (container to hold both
-W<sup>-</sup> and W<sup>+</sup> boson), <code>t</code> (top quark),
-<code>t~</code> (anti-top),
-<code>dl</code>, <code>dl~</code>, <code>ul</code>, <code>ul~</code>,
-<code>sl</code>, <code>sl~</code>, <code>cl</code>, <code>cl~</code>,
-<code>b1</code>, <code>b1~</code>, <code>t1</code>, <code>t1~</code>,
-<code>dr</code>, <code>dr~</code>, <code>ur</code>, <code>ur~</code>,
-<code>sr</code>, <code>sr~</code>, <code>cr</code>, <code>cr~</code>,
-<code>b2</code>, <code>b2~</code>, <code>t2</code>, <code>t2~</code> (all MSSM
-squarks).
-
-<p/>
-We have pre-defined the outgoing particles:
-<code>e+</code>, <code>e-</code>, <code>ve~</code>,
-<code>ve</code>, <code>mu+</code>, <code>mu-</code>,
-<code>vm~</code>, <code>vm</code>, <code>ta+</code>, <code>ta-</code>,
-<code>vt~</code>, <code>vt</code> (all SM leptons and neutrinos),
-<code>j~</code> (container to hold all final state coloured particles),
-<code>j</code> (container to hold all final state coloured particles),
-<code>NEUTRINOS</code> (container to hold all final state neutrinos and
-anti-neutrinos), <code>LEPTONS</code> (container to hold all final state
-leptons and anti-leptons), <code>BQUARKS</code> (container to hold final
-state b-quarks), <code>d~</code>, <code>d</code>, <code>u~</code>,
-<code>u</code>, <code>s~</code>, <code>s</code>, <code>c~</code>,
-<code>c</code>, <code>b~</code>, <code>b</code>, <code>t~</code>,
-<code>t</code> (all SM quarks), <code>a</code>, <code>z</code>,
-<code>w-</code>, <code>w+</code> (all SM electro-weak bosons),
-<code>h</code> (scalar Higgs boson), <code>W</code> (container to hold both
-W<sup>-</sup> and W<sup>+</sup> boson), <code>n1</code> (MSSM neutralino),
-<code>dl~</code>, <code>dl</code>, <code>ul~</code>, <code>ul</code>,
-<code>sl~</code>, <code>sl</code>, <code>cl~</code>, <code>cl</code>,
-<code>b1~</code>, <code>b1</code>, <code>t1~</code>, <code>t1</code>,
-<code>dr~</code>, <code>dr</code>, <code>ur~</code>, <code>ur</code>,
-<code>sr~</code>, <code>sr</code>, <code>cr~</code>, <code>cr</code>,
-<code>b2~</code>, <code>b2</code>, <code>t2~</code>, <code>t2</code>
-(all MSSM squarks). Other outgoing particles are possible if you use the
-"curly bracket notation" described earlier.
-
-<br/><br/><hr/>
-<h3>Histogramming the events</h3>
-After the event has been processed, histograms for observables of interest
-need to be filled. In order to achieve good statistical accuracy for all jet
-multiplicities and all subprocesses contributing to one jet multiplicity,
-generally a fixed number of unit-weighted events is read from each Les
-Houches Event file. To then arrive at the correct prediction, for each of these
-events, histogram bins should be filled with the corresponding cross
-section, or weighted with unit weight and normalised at the end to
-the generated cross section for each jet multiplicity separately.
-
-<p/> Still another, even more important, event weight that has to
-applied on an event-by-event basis is the CKKW-L-weight. This
-corrective weight is the main outcome of the merging procedure and
-includes the correct no-emission probabilities, PDF weights and
-α<sub>s</sub> factors. This means that the merging
-implementation will generate weighted events. The CKKW-L-weight can be
-accessed by the following function:
-
-<p/><strong> double Info::mergingWeight() </strong> <br/>
-Returns the CKKW-L weight for the current event.
-
-<p/> Note that to avoid confusion, this function does not include the
-the weight of a phase space point (given
-by <strong>Info::weight()</strong>). This weight will differ from
-unity when reading in weighted Les Houches events. In this case, the
-full weight with which to fill histogram bins is
-<strong>Info::mergingWeight() * Info::weight()</strong>.
-
-<p/> Finally, to arrive at a correct relative normalisation of the
-contributions from different number of additional jets in the matrix
-element, each histogram should be rescaled with the accepted cross
-section given by
-<strong>Info::sigmaGen()</strong>. The accepted cross section includes
-the effect of vetoes generating Sudakov form factors for the matrix
-elements, and is in general only known after the run.
-
-<p/> This final step can of course be skipped if the accepted cross
-section had been estimated before the histogramming run, and histogram
-bins had instead been filled with the weight
-<strong>Info::mergingWeight() * σ<sub>est</sub>(number of
-additional jets in current ME sample)</strong>. This is the way HepMC
-events should be weighted to produce correct relative weights of
-events (see below, and particularly examine the example program
-<code>main84.cc</code>).
-
-<p/> Examples how to use these options are given in <code>main81.cc</code>
-(<ei>kT</ei> merging) and <code>main84.cc</code> (automatic MG/ME merging
-for RIVET usage).
-
-<br/><br/><hr/>
-<h3>Merging with user-defined merging scale function</h3>
-
-<p/> For all other merging scale definitions, the procedure is
-slightly more complicated, since the user has to write a small piece
-of code defining the merging scale. To allow for a user defined
-procedure, set the input
-
-<flag name="Merging:doUserMerging" default="off">
-General user defined merging on/off.
-</flag>
-
-</p>
-Then, set
-the <strong>Merging:nJetMax</strong>, <strong>Merging:TMS</strong>
-and <strong>Merging:Process</strong> input as before.
-
-<p/> Since during execution, PYTHIA needs to evaluate the merging
-scale with the definition of the user, the user interface is designed
-in a way similar to the
-<code>UserHooks</code> strategy. The class controlling the merging
-scale definition is called <code>MergingHooks</code>.
-
-<h4>Initialisation</h4>
-
-<p/> To initialise the merging with user-defined merging scale, we
-should construct a class derived from <code>MergingHooks</code>, with
-a constructor and destructor
-
-<p/>
-<method name="MergingHooks::MergingHooks()">
-</method>
-<method name="virtual MergingHooks::~MergingHooks()">
-</method>
-The constructor and destructor do not need to do anything.
-
-<p/> For the class to be called during execution, a pointer to an
-object of the class should be handed in with the
-<br/><code><a href="ProgramFlow.html" target="page">
-Pythia::setMergingHooksPtr( MergingHooks*)</a></code> method.
-
-An examples of this procedure are given in <code>main82.cc</code>.
-
-<h4>Defining a merging scale</h4>
-
-<p/> Then, in the spirit of the <code>UserHooks</code> class, the user
-needs to supply the process to be merged by defining a methods to
-evaluate the merging scale variable.
-
-<method name="virtual double MergingHooks::tmsDefinition(const Event& event)">
-This method will have to calculate the value of the merging scale
-defined in some variable from the input event record. An example of
-such a function is given in <code>main82.cc</code>.
-</method>
-
-<p/> The base class <code>MergingHooks</code> contains many functions
-giving information on the hard process, to make the definition of the
-merging scale as easy as possible:
-
-<method name="int MergingHooks::nMaxJets()">
-Return the maximum number of additional jets to be merged.
-</method>
-
-<method name="int MergingHooks::nHardOutPartons()">
-Returns the number of outgoing partons in the hard core process.
-</method>
-
-<method name="int MergingHooks::nHardOutLeptons()">
-Returns the number of outgoing leptons in the hard core process.
-</method>
-
-<method name="int MergingHooks::nHardInPartons()">
-Returns the number of incoming partons in the hard core process.
-</method>
-
-<method name="int MergingHooks::nHardInLeptons()">
-Returns the number of incoming leptons in the hard core process.
-</method>
-
-<method name="int MergingHooks::nResInCurrent()">
-The number of resonances in the hard process reconstructed from the
-current event. If e.g. the ME configuration was
-<ei>pp -> (w+->e+ve)(z -> mu+mu-)jj</ei>, and the ME generator put
-both intermediate bosons into the LHE file, this will return 2.
-</method>
-
-<method name="double MergingHooks::tms()">
- Returns the value used as the merging scale.
-</method>
-
-<p/> Filling output histograms for the event then proceeds along the
-lines described above in "Histogramming the events".
-
-<p/> The full procedure is outlined in <code>main82.cc</code>. Special
-care needs to be taken when the output is stored in the form of HepMC
-files for RIVET usage.
-
-<h4>Defining a cut on lowest jet multiplicity events</h4>
-
-<p/> It can sometimes happen that when generating LHE files, a fairly
-restrictive cut has been used when generating the lowest multiplicity
-matrix element configurations. Then, it can happen that states that
-are (in the generation of a parton shower history) constructed by
-reclustering from higher multiplicity configurations, do not pass
-this matrix element cut.
-
-<p/> Consider as an example pure QCD dijet merging, when up to one
-additional jet should be merged. Three-jet matrix element
-configurations for which the reclustered two-jet state does not pass
-the cuts applied to the two-jet matrix element would never have been
-produced by showering the two-jet matrix element. This means that the
-three-jet matrix element includes regions of phase space that would
-never have been populated by the parton shower. Thus, since the
-matrix element phase space is larger than the shower phase space,
-merging scale dependencies are expected. A priori, this is not
-troublesome, since the aim of matrix element merging is to include
-regions of phase space outside the range of the parton shower
-approximation into the shower. An example is the inclusion of
-configurations with only unordered histories.
-
-<p/> Clearly, if the parton shower phase space is very constrained by
-applying stringent cuts to the two-jet matrix element, merging scale
-dependencies can become sizable, as was e.g. seen in <ref>Lon11</ref>
-when forcing shower emissions to be ordered both in the evolution
-variable and in rapidity. To influence the effect of large phase
-space differences for shower emissions and matrix element
-configurations due to LHEF generation cuts, the user has to write a
-small piece of code overwriting method
-
-<method
- name="virtual double MergingHooks::dampenIfFailCuts(const Event&
-event)"> This routine will be supplied internally with the lowest
-multiplicity reclustered state as an input Event. From this input
-event, the user can then check if matrix element cuts are
-fulfilled. The return value will be internally multiplied to the
-CKKW-L weight of the current event. Thus, if the user wishes to
-suppress contributions not passing particular cuts, a number smaller
-than unity can be returned.
-</method>
-
-<p/> Note that this method gives the user access to the lowest
-multiplicity state, which ( e.g. in the case of incomplete histories)
-does not have to be a <ei>2 → 2</ei> configuration. Also, changing the
-weight of the current event by hand is of course a major intervention
-in the algorithm, and should be considered very carefully. Generally,
-if this facility would have to be used extensively, it is certainly
-preferable to be less restrictive when applying additional,
-non-merging-scale-related cuts to the matrix element.
-
-<p/> An example how to force a cut on lowest multiplicity reclustered
-states for pure QCD matrix element configurations is given by
-<code>main83.cc</code> (to be used with e.g. <code>main82.cmnd</code>).
-
-<h4>Influencing the construction of all possible histories</h4>
-
-<p/> Even more powerful - and dangerous - is influencing the construction
-of histories directly. This should only be attempted by expert users. If you
-believe manipulations completely unavoidable, we advise you to take great care
-when redefining the following functions.
-
-<method name="virtual bool MergingHooks::canCutOnRecState()">
-In the base class this method returns false. If you redefine it
-to return true then the method <code>doCutOnRecState(...)</code>
-will be called for each reclustered state encountered in the generation of
-all possible histories of the matrix element state.
-</method>
-
-<method name="virtual bool MergingHooks::doCutOnRecState(const Event&
-event)">
-This routine will be supplied internally with every possible reclustered
-event that can be reached by reclustering any number of partons in
-the matrix element input state. The new, reclustered, states can then be
-analysed. If the method returns false, the history to which the state belongs
-will be treated as if it were unordered, i.e. this path will only be chosen
-if no other histories are available. In this way, the number of histories
-not fulfilling the user criterion will be minimised.
-</method>
-
-<p/>
-Clearly, these methods are highly intrusive. It could e.g. happen that no
-history is allowed, which would make merging impossible. One example where
-this method could be useful is if cuts on the core <ei>2 -> 2</ei> processes
-have to be checked, and the method
-<code>MergingHooks::dampenIfFailCuts(const Event& event)</code> is not
-sufficiently effective.
-
-
-<br/><br/><hr/>
-<h3>Matrix element merging and HepMC output for RIVET</h3>
-
-An example how to produce matrix element merged events to be analysed
-with RIVET is given by <code>main84.cc</code>.
-
-<p/> The main issue is that the output of separate RIVET runs can not
-in general be combined. To perform a matrix element merging, we
-however need to runs over different LHE files. The solution to this
-problem (so far) is to only perform one RIVET run for all matrix
-elements, i.e. print the events for all ME parton multiplicities,
-with the correct weights, to a single HepMC file. Since the correct
-weight includes the cross section of the different samples after
-Sudakov vetoes --- which is not a priori known --- the cross sections
-have to be estimated in a test run, before the actual production run
-is performed. Finally, the cross section of the last event in the
-HepMC file has to be taken as the full merged cross section
-<ei>sigma_merge = Sum_{i=0}^N Sum_{j=0}*^{nEvents}
-sigma_est(i)*wckkwl(j)</ei>.
-
-<p/> This procedure is outlined in <code>main84.cc</code>.
-
-<br/><br/><hr/>
-<h3>Further variables</h3>
-
-For more advanced manipulations of the merging machinery, all
-parameter changes that were investigated in <ref>Lon11</ref> are
-supplied. Please check <ref>Lon11</ref> for a detailed discussion of
-the switches.
-
-<p/> These switches allow enthusiastic users to perform a systematic
-assessment of the merging prescription. Apart from this, we advise the
-non-expert user to keep the default values.
-
-<flag name="Merging:includeMassive" default="on">
-If on, use the correct massive evolution variable and massive
-splitting kernels in the reconstruction and picking of parton shower
-histories of the matrix element. If off, reconstruct evolution
-scales, kinematics and splitting kernels as if all partons were
-massless.
-</flag>
-
-<flag name="Merging:enforceStrongOrdering" default="off">
-If on, preferably pick parton shower histories of the matrix element
-which have strongly ordered consecutive splittings, i.e. paths in
-which consecutive reclustered evolution scales are separated by a
-user-defined factor.
-</flag>
-
-<parm name="Merging:scaleSeparationFactor" default="1.0" min="1.0" max="10.0">
-The factor by which scales should differ to be classified as strongly
-ordered.
-</parm>
-
-<flag name="Merging:orderInRapidity" default="off">
-If on, preferably pick parton shower histories of the matrix element
-with consecutive splittings ordered in rapidity and <ei>pT</ei>.
-</flag>
-
-<flag name="Merging:pickByFullP" default="on">
-If on, pick parton shower histories of the matrix element by the full
-shower splitting kernels, including potential ME corrections and
-Jacobians from joined evolution measures.
-</flag>
-
-<flag name="Merging:pickByPoPT2" default="off">
-If on, pick parton shower histories of the matrix element by the
-shower splitting kernels divided by the evolution <ei>pT</ei>.
-</flag>
-
-<flag name="Merging:pickBySumPT" default="off">
-If on, exclusively pick parton shower histories of the matrix element
-for which have the smallest sum of scalar evolution <ei>pT</ei> for consecutive
-splittings has been calculated.
-</flag>
-
-<flag name="Merging:includeRedundant" default="off">
-If on, then also include PDF ratios and <ei>α<sub>s</sub></ei>
-factors in the splitting probabilities used for picking a parton shower
-history of the matrix element, when picking histories by the full shower
-splitting probability. As argued in <ref>Lon11</ref>, this should not
-be done since a reweighting with PDF ratios and <ei>α<sub>s</sub></ei>
-factors will be performed. However, it can give useful insight in how
-sensitive the results are to the prescription on how to choose PS
-histories.
-</flag>
-
-<parm name="Merging:nonJoinedNorm" default="1.0" min="0.0" max="10.0">
-Normalisation factor with which to multiply splitting probability for
-splittings without joined evolution equation.
-</parm>
-
-<parm name="Merging:fsrInRecNorm" default="1.0" min="0.0" max="10.0">
-Normalisation factor with which to multiply splitting probability for
-final state splittings with an initial state recoiler.
-</parm>
-
-<parm name="Merging:aCollFSR" default="1.0" min="0.0" max="10.0">
-Factor with which to multiply the scalar <ei>pT</ei> of a final state
-splitting, when choosing the history by the smallest sum of scalar
-<ei>pT</ei>. Default value taken from Herwig++ <ref>Tul09</ref>.
-</parm>
-
-<parm name="Merging:aCollISR" default="0.9" min="0.0" max="10.0">
-Factor with which to multiply the scalar <ei>pT</ei> of an initial state
-splitting, when choosing the history by the smallest sum of scalar
-<ei>pT</ei>. Default value taken from Herwig++ <ref>Tul09</ref>.
-</parm>
-
-<modepick name="Merging:unorderedScalePrescrip" default="0" min="0" max="1">
-When the parton shower history of the matrix element contains a
-sequence of splittings which are not ordered in evolution <ei>pT</ei>
-(called an unordered history), this sequence is interpreted as a combined
-emission. Then, a decision on which starting scale for trial emissions
-off reconstructed states in this sequence of unordered splittings has
-to be made. Two options are available:
-<option value="0"> Use larger of the two reconstructed (unordered)
-scales as starting scale.
-</option>
-<option value="1"> Use smaller of the two reconstructed (unordered)
-scales as starting scale.
-</option>
-</modepick>
-
-<modepick name="Merging:unorderedASscalePrescrip" default="1" min="0" max="1">
-Prescription which scale to use to evaluate <ei>α<sub>s</sub></ei>
-weight for splittings in a sequence of splittings which are not ordered
-in evolution <ei>pT</ei>.
-<option value="0"> Use the combined splitting scale as argument in
-<ei>α<sub>s</sub></ei>, for both splittings.
-</option>
-<option value="1"> Use the true reconstructed scale as as argument in
-<ei>α<sub>s</sub></ei>, for each splitting separately.
-</option>
-</modepick>
-
-<modepick name="Merging:unorderedPDFscalePrescrip" default="0" min="0" max="1">
-Prescription which scale to use to evaluate ratios of parton distibutions
-for splittings in a sequence of splittings which are not ordered
-in evolution <ei>pT</ei>.
-<option value="0"> Use the combined splitting scale as argument in PDF ratios,
-for both splittings.
-</option>
-<option value="1"> Use the true reconstructed scale as argument in PDF
-ratios, for each splitting separately.
-</option>
-</modepick>
-
-<modepick name="Merging:incompleteScalePrescrip" default="0" min="0" max="2">
-When no complete parton shower history (i.e. starting from a
-<ei>2 → 2</ei> process) for a matrix element with additional jets
-can be found, such a configuration is said to have an incomplete history.
-Since in incomplete histories, not all shower starting scales are
-determined by clusterings, a prescription for setting the starting scale
-of trial showers in incomplete histories is needed. Three options are
-provided.
-<option value="0"> Use factorisation scale as shower starting scale
-for incomplete histories.
-</option>
-<option value="1"> Use <ei>sHat</ei> as shower starting scale for
-incomplete histories.
-</option>
-<option value="2"> Use <ei>s</ei> as shower starting scale for
-incomplete histories.
-</option>
-</modepick>
-
-<flag name="Merging:allowColourShuffling" default="off">
-If on, this will allow the algorithm to swap one colour index in the state,
-when trying to find all possible clusterings, if no clustering has been
-found, but more clusterings had been requested. In this way, some incomplete
-histories can be avoided. Generally, we advise the non-expert user to not
-touch this switch, because a slight change in the colour structure can change
-the radiation pattern. To however study the sensitivity of the predictions on
-these effects, allowing for colour reshuffling can be useful.
-</flag>
-
-<flag name="Merging:usePythiaQRenHard" default="on">
-If on, this will allow the algorithm to use a dynamical renormalisation scale
-to evaluate the strong couplings of the core hard process in dijet and
-prompt photon events.
-This means that the value of <ei>α<sub>s</sub></ei> used as coupling
-of the hard process in the matrix element generation will be replaced with
-a running coupling evaluated at the geometric mean of the squared transverse
-masses of the two outgoing particles, as is the default prescription in
-Pythia.
-</flag>
-
-<flag name="Merging:usePythiaQFacHard" default="on">
-If on, this will allow the algorithm to use a dynamical factorisation scale
-to evaluate parton distributions associated with the hadronic cross section
-of the core hard process in dijet and prompt photon events.
-In the calculation of PDF ratios as part of the CKKW-L weight of an event,
-parton distributions that should be evaluated at the scale of the core
-2 - >2 process will be evaluated using the dynamical factorisation scale
-Pythia would attribute to this process. This means that the hard process
-factorisation scale is set to the smaller of the squared transverse masses
-of the two outgoing particles.
-</flag>
-
-</chapter>
-
-<!-- Copyright (C) 2012 Torbjorn Sjostrand -->
\ No newline at end of file
git://git.uio.no / u / mrichter / AliRoot.git / blobdiff