Unitarised Matrix Element + Parton Shower Merging

Pythia offers the possibility to use the unitarised matrix element + parton shower merging scheme, as presented in [Lon12]. Unitarised ME+PS merging (UMEPS) allows for a consistent inclusion of tree-level multi-parton matrix elements into Pythia, and prevents potential changes in the inclusive production cross section. This makes it theoretically more appealing than CKKW-L merging. As in CKKW-L, UMEPS merging requires the user to supply Les Houches Event File input.

UMEPS is different from other tree-level merging schemes in that it contains events with negative weights. These are generated by constructing parts of no-emission probabilities by reweighted higher-multiplicity samples [Lon12]. The main philosophy of UMEPS is "subtract what you add", meaning that in order to ensure the stability of the inclusive cross section, one has to counter the inclusion of additional tree-level matrix elements by "subtraction terms".

The scheme closely reflects how unitarity is achieved in a non-merged shower, and indeed explicitly enforces the cancellations that are implicitly happening in a non-merged shower. This makes very low merging scale values possible.

The usage of UMEPS is illustrated in the input file main162umeps.cmnd for main162.cc.

Unitarised merging is heavily indebted to CKKW-L merging, and shares many settings with CKKW-L. In particular,

         The hard process (Merging:Process)needs to be defined exactly as in CKKW-L (see Defining the hard process in the CKKW-L documentation).

         The merging scale value (Merging:TMS) has to be set.

         The maximal number of additional partons Merging:nJetMax has to be set.

UMEPS further shares the switches listed under the sections "Matrix element merging and HepMC output for RIVET" and "Further variables" in the CKKW-L documentation with CKKW-L merging. Also, all MergingHooks routines that allow for user interference in CKKW-L merging are also usable for UMEPS -- with the exception of a user-defined merging scale. Currently, UMEPS is only implemented for a merging scale defined by the minimal Pythia evolution pT value between sets of radiator, emitted and recoiler partons. This is no fundamental limitation of the method, and will possibly be lifted in the future. Since this merging scale definition is not completely obvious, UMEPS also shares the Merging:enforceCutOnLHE switch with CKKW-L. In this way, it is possible to use LHE files that are regularised only with weak cuts as input, while the merging machinery imposes the stronger merging scale cut automatically. This means that no merging scale implementation is required from the user side, but also means that it is the user's responsibility to ensure that the cuts used for generating input LHE files are always looser than the cut given by the merging scale value Merging:TMS.

UMEPS merging with main162.cc

The UMEPS procedure is illustrated in the input card main162umeps.cmnd for main162.cc. This program produces HepMC events [Dob01], that can be histogrammed (e.g. using RIVET [Buc10]), or used as input for a detector simulation. If the user is not familiar with HepMC analysis tools, it is possible to instead use Pythia's histogramming routines. For this, remove the lines referring to HepMC, and histogram events as illustrated (for CKKW-L) for the histogram histPTW in main161.cc, i.e. using weight*norm as weight.

In principle, no changes to main162.cc are necessary. Instead, all settings can be transferred to main162.cc through an input file. The input LHE files are part of the command file main162umeps.cmnd.

Inputs

In its current form, main162.cc uses separate tree-level LHE files for different numbers of additional partons as input. If e.g. UMEPS merging for W-boson + up to two additional partons is to be performed, three LHE files (for W+zero, W+one, W+two partons) are required. The configurations in the input files should be regularised with inclusive (i.e. weak) cuts. The actual "merging scale cut" will be handled internally. If e.g. Merging:TMS = 15 is the desired merging scale value, it is acceptable to regularise the matrix element calculation for Higgs+jets events at the LHC with the loose cuts pTjet = 5 GeV, ΔRjetA jetB = 0.01 and QjetA jetB = 5 GeV.

All input settings are handed to main162.cc in the form of an input file. This input file has to contain

         The number of desired events (Main:numberOfEvents)

         The hard process (Merging:Process)

         The merging scale value (Merging:TMS)

         The maximal number of additional partons (Merging:nJetMax).          The number of subruns (for UMEPS 2*nJetMax-1 are needed)          One subrun for each multiplicity and treatment, starting with Main:subrun = <nSubrun>

Other settings are of course allowed. However, please refrain from adding switches that are used to invoke other merging schemes (e.g. Merging:doKTMerging) into the input file, since this can cause problems.

Program flow

The sample program starts by estimating the cross section for samples with different jet multiplicities. For this, the switch Merging:doXSectionEstimate is invoked together with the merging scale definition of Merging:doUMEPSTree, which corresponds to the minimal Pythia evolution pT value. We will come back to the latter switch below. All showering, multiparton interactions and hadronization is, for speed reasons, switched off when estimating the cross section, since the hard cross section estimate would not be influenced by the event evolution anyway.

After the hard cross sections are known (including the application of the merging scale cut), the first part of the UMEPS events is generated by using the following switch.

flag  Merging:doUMEPSTree   (default = off)
Reweight events according to the UMEPS prescription for tree-level configurations.

The weight generated by the UMEPS procedure can be accessed by using the function double Info::mergingWeight(). When printing (or histogramming) merged events, this weight, multiplied with the estimated cross section for the current sample, should be used as event weight (or to fill histogram bins).

After this first part is complete, the outcome is an addition of reweighted tree-level samples. To restore the inclusive cross section (i.e. that the cross section after merging corresponds to the cross section of the hard process, without any additional jets), it is necessary to subtract samples. Parton shower unitarity leads to the conclusion that "resolved" and "unresolved" corrections always cancel between states that contain an additional resolved jet, and states in which we "integrate over" the phase space of the additional jet. UMEPS makes this cancellation explicit by producing (correctly weighted) counter events by switching on

flag  Merging:doUMEPSSubt   (default = off)
Reweight events according to the UMEPS prescription of reweighted, integrated configurations. Please note that, in order for this to work smoothly, the switch Merging:doUMEPSTree has to be turned off.

The integration is achieved internally, and the number of desired integrations (which is always one for UMEPS counter events) is set by

mode  Merging:nRecluster   (default = 0; minimum = 0)
Number of hard partons to integrate out in the UMEPS procedure.

Again, the weight generated by the UMEPS procedure can be accessed by using the function double Info::mergingWeight(). This weight, multiplied with the cross section of the current sample, and multiplied by -1, should then be used as event weight (or to fill histogram bins).

Finally, main162.cc prints the merged cross section after UMEPS merging.