main86.cc, together with the input file
main86.cmnd. 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:nJetMaxhas 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
MergingHooksroutines 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:enforceCutOnLHEswitch 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
main86.cc(with the input card
main86.cmnd). 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 histPTFirstSum in
main84.cc, i.e. using weight*normhepmc as weight. In principle, no changes to
main86.ccare necessary. Instead, all settings can be transferred to
main86.ccthrough an input file. The input LHE files are also part of the (command line) input of
main86.cc. Note that the sample program assumes that LHE file names are of the form name_tree_#nAdditionalJets.lhe. If you want to e.g. use the LHE files that are shipped with the Pythia distribution, you can execute
main86.exewith the command
./main86.exe ./main86.cmnd ./w_production ./myhepmc.hepmc
main86.ccis currently the "front-end" for UMEPS merging, we will briefly discuss this sample program in the following.
main86.ccuses 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 = 15is 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
main86.ccin 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). 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.
Merging:doXSectionEstimateis 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 hadronisation 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.
default = off)
main86.ccmakes this cancellation explicit by producing (correctly weighted) counter events by switching on
default = off)
Merging:doUMEPSTreehas 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
default = 0;
minimum = 0)
main86.ccprints the merged cross section after UMEPS merging.