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: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
.
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.cc
are necessary. Instead, all
settings can be transferred to main86.cc
through 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.exe
with the command
./main86.exe ./main86.cmnd ./w_production ./myhepmc.hepmc
main86.cc
is currently the "front-end" for UMEPS merging,
we will briefly discuss this sample program in the following.
main86.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 main86.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
).
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: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 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.
flag
Merging:doUMEPSTree
(default = off
)main86.cc
makes this cancellation explicit by producing
(correctly weighted) counter events by switching on
flag
Merging:doUMEPSSubt
(default = off
)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
)main86.cc
prints the merged cross section
after UMEPS merging.