flag
Vincia:matching
(default = on
)Vincia = on
, when using VINCIA matching,
see the section on the VINCIA shower.
A small library of matrix elements obtained with MADGRAPH (MG) are included with the standard VINCIA release. (In the future, matrix elements for additional processes will be available for download from the VINCIA homepage.) Through its MG interface, VINCIA is able to match to these matrix elements during the shower evolution.
flag
Vincia:MGInterface
(default = on
)Note: see the section on Useful References for additional references to include when using the matrix elements provided by this interface.
Note 2: parts of the MADGRAPH code (specifically the HELAS libraries) are needed at runtime to evaluate the MADGRAPH matrix elements. The Makefile distributed with VINCIA will automatically attempt to download and install the MADGRAPH standalone tarball for you, if it doesn't find it in the expected location, and will then compile the relevant libraries from it. If this fails, we recommend having a look in the Makefile before contacting the authors. Large parts of the Makefile have been made user-editable in hopefully straightforward ways, and it may be possible for you to solve the problem by trivial editing.
Note 3: The MADGRAPH matrix elements included with VINCIA are
located together with the actual interface code
in the MGInterface/
subdirectory. They
are ordinary MADGRAPH matrix element routines, which have been
renamed and modified slightly for use by VINCIA. Most of this
conversion is done automatically, by a script. Implementing new
matrix elements should therefore be fairly trivial, as long as the
final state corresponds to something that VINCIA can actually
generate. (E.g., implementing matrix elements for DIS or
hadron-collider processes will not suddenly make VINCIA able to
handle such cases, since the shower is not yet developed for that.)
For explicit instructions on how to implement new matrix
elements and make them available to VINCIA at runtime, we recommend
contacting the authors for a brief how-to.
mode
Vincia:matchingStrategy
(default = 1
; minimum = 1
; maximum = 3
)option
1 : Multiplicative (a.k.a. merging, or branching reweighting).
option
2 : Hybrid.
Not implemented, placeholder only.
option
3 : Additive (a.k.a. event reweighting).
Not implemented, placeholder only.
mode
Vincia:maxMatchTree
(default = 3
; minimum = 0
; maximum = 4
)2
would invoke tree-level matching
up to and including X+2
partons, to the extent the
relevant matrix elements are available in the code. The
value 0
is equivalent to switching matching off.
mode
Vincia:maxMatchLoop
(default = 0
; minimum = 0
; maximum = 0
)0
is equivalent to switching off one-loop matching,
(since the first one-loop correction arises at one power beyond the
Born). Setting it to 1
invokes one-loop matching of the Born process, 2
extends the 1-loop matching to X+1
partons (2 powers
beyond the Born), etc. As for the tree-level switch, the matching
will only take place to the extent the relevant matrix
elements are available in the code.
mode
Vincia:matchingColorDepth
(default = 1
; minimum = 0
; maximum = 1
)option
0 : Leading Color. Only include matching to leading-color matrix
elements.
option
1 : Full Color. Include the full color structure of the
matched matrix elements, absorbing the subleading-color pieces into
each leading-color one in proportion to the relative sizes of the
leading-color pieces. This procedure effectively diagonalizes the
full color matrix and has been checked to result in positive-definite
corrections for all the matrix elements so far implemented in large
scans (order of 1 million points) over phase space.
We use the term matching scale to refer to a generic sharp or smooth dampening of the ME corrections as one crosses a specified pT threshold in phase space. The purpose of this is to restrict the matching to regions of phase space that are free from subleading logarithmic divergences in the matrix elements. This is familiar from the CKKW and MLM approaches, where the matching scale is imposed as a step function in pT, with full ME corrections above that scale and no ME corrections below it. In order to make things a bit more smooth, we instead use the following smooth cutoff to impose our matching scale
The additive matching type (see below) requires a matching scale to be imposed starting from second order in QCD (e.g., Z->4, equivalent to the NLL level), similarly to the case for CKKW and MLM matching. The multiplicative matching type, however, exponentiates the ME corrections at second order and therefore only requires a matching scale to be imposed starting from third order in QCD (e.g., Z->5, equivalent to the NNLL level). We note, however, that even in the case of multiplicative matching, the automatic evaluation of uncertainty weights is still basically additive and therefore still relies on a matching scale already at the NLL level.mode
Vincia:matchingScaleType
(default = 1
; minimum = 1
; maximum = 2
)option
1 : Relative. Matching scale is determined automatically
in relation to the hard scale in the process (e.g., the Z mass) by
the factor Vincia:matchingScaleRatio
below. This is the
default option and the one recommended for non-experts. It should
allow a wide range of processes to be considered without having to
manually adjust the matching scale.
option
2 : Absolute. The matching scale is set by the
value Vincia:matchingScale
(in GeV). Care must then be
taken to select a matching scale appropriate to the specific process
and hard scales under consideration. For non-experts, the relative
method above is recommended instead.
parm
Vincia:matchingScaleRatio
(default = 0.1
; minimum = 0.0
; maximum = 1.0
)Vincia:matchingScaleType = 1
, this sets the
ratio of the matching scale to the process-dependent hard scale. Since the
unresummed logarithms depend on ratios of scales, it is more natural to express the matching scale in this way. Note that this parameter
should normally not be varied by more than a factor of 2 in either
direction. The default value has been chosen so as to allow one order
of magnitude between the hard scale and the matching scale. Setting it
too close to unity will effectively switch off the matching, even at
high scales. Settings below around 0.1 risks re-introducing unresummed
logarithms in the matching coefficients.
parm
Vincia:matchingScale
(default = 20.0
; minimum = 0.0
)Vincia:matchingScaleType = 2
, this sets the
absolute value of the matching scale, in GeV. Care must be taken to select a matching scale appropriate to the specific process and hard scales under consideration.
Care has been taken to ensure that all events generated by VINCIA have weights which are positive and equal to unity. Indeed, this property is central both to the shower and to the multiplicative matching scheme. Ordinary runs should therefore produce a simple set of unweighted events, equivalent to normal Pythia 8 output.
However, Vincia does allow for
negative weights and/or weights greater than unity to be generated,
for instance if additive matching is used and/or if
settings have been chosen so extreme that large
negative or positive corrections become unavoidable, or in case the
future subleading-color corrections turn out to require the
generation negative weights. In these cases, warnings
will be printed to the standard output.
If changes to the event weight are made, these are
properly bookkept and the final weight is accessible after
the event has been fully generated through the weight()
method in the Vincia plugin. For instance, if the
VinciaPlugin
object is called vincia
the
generated event weight can be accessed by
vincia.weight();
Convenient yes/no shorthands for checking whether any negative weights w < 0 and/or any non-unity weights abs(w) > 1 have been generated at all (during the current run) are provided by the methods
bool vincia.negativeWeightOccurred();
bool vincia.nonunityWeightOccurred();
Note that Vincia's weights fully include any non-unity
input weights associated with the event from Pythia (normally,
Pythia's weights are unity, but when using external events, e.g., from
LHEF files, these can in principle come with non-unity weights).
The weight Vincia started from is
not modified and remains accessible through Pythia's
own info.weight()
method.
parm
Vincia:headRoomFactor
(default = 1.1
; minimum = 1.0
; maximum = 10.0
)