Matching and Merging

• A formal order-by-order perturbative calculation, in each order higher including graphs both with one particle more in the final state and with one loop more in the intermediate state. This is accurate to the order of the calculation, but gives no hint of event structures beyond that, with more particles in the final state. Today next-to-leading order (NLO) is standard, while next-to-next-to-leading order (NNLO) is coming. This approach thus is limited to few orders, and also breaks down in soft and collinear regions, which makes it unsuitable for matching to hadronization.
• Real emissions to several higher orders, but neglecting the virtual/loop corrections that should go with it at any given order. Thereby it is possible to allow for topologies with a large and varying number of partons, at the prize of not being accurate to any particular order. The approach also opens up for doublecounting, and as above breaks down in soft and colliner regions.
• The parton shower provides an approximation to higher orders, both real and virtual contributions for the emission of arbitrarily many particles. As such it is less accurate than either of the two above, at least for topologies of well separated partons, but it contains a physically sensible behaviour in the soft and collinear limits, and therefore matches well onto the hadronization stage.

The common traits of all combination methods are that matrix elements are used to describe the production of hard and well separated particles, and parton showers for the production of soft or collinear particles. What differs between the various approaches that have been proposed are which matrix elements are being used, how doublecounting is avoided, and how the transition from the hard to the soft regime is handled. These combination methods are typically referred to as "matching" or "merging" algorithms. There is some confusion about the distinction between the two terms, and so we leave it to the inventor/implementor of a particular scheme to choose and motivate the name given to that scheme.

PYTHIA comes with methods, to be described next, that implement or support several different kind of algorithms. The field is open-ended, however: any external program can feed in Les Houches events that PYTHIA subsequently showers, adds multiparton interactions to, and hadronizes. These events afterwards can be reweighted and combined in any desired way. The maximum pT of the shower evolution is set by the Les Houches scale, on the one hand, and by the values of the SpaceShower:pTmaxMatch, TimeShower:pTmaxMatch and other parton-shower settings, on the other. Typically it is not possible to achieve perfect matching this way, given that the PYTHIA pT evolution variables are not likely to agree with the variables used for cuts in the external program. Often one can get close enough with simple means but, for an improved matching, User Hooks can be inserted to control the steps taken on the way, e.g. to veto those parton shower branchings that would doublecount emissions included in the matrix elements.

Zooming in from the "anything goes" perspective, the list of relevent approaches actively supported is as follows.

• For many/most resonance decays the first branching in the shower is merged with first-order matrix elements [Ben87, Nor01]. This means that the emission rate is accurate to NLO, similarly to the POWHEG strategy (see below), but built into the timelike showers. The angular orientation of the event after the first emission is only handled by the parton shower kinematics, however. Needless to say, this formalism is precisely what is tested by Z^0 decays at LEP1, and it is known to do a pretty good job there.
• Also the spacelike showers contain a correction to first-order matrix elements, but only for the one-body-final-state processes q qbar → gamma^*/Z^0/W^+-/h^0/H^0/A0/Z'0/W'+-/R0 [Miu99] and g g → h^0/H^0/A0, and only to leading order. That is, it is equivalent to the POWHEG formalism for the real emission, but the prefactor "cross section normalization" is LO rather than NLO. Therefore this framework is less relevant, and has been superseded the following ones.
• The POWHEG strategy [Nas04] provides a cross section accurate to NLO. The hardest emission is constructed with unit probability, based on the ratio of the real-emission matrix element to the Born-level cross section, and with a Sudakov factor derived from this ratio, i.e. the philosophy introduced in [Ben87].
  While POWHEG is a generic strategy, the POWHEG BOX [Ali10] is an explicit framework, within which several processes are available. The code required for merging the PYTHIA showers with POWHEG input can be found in include/Pythia8Plugins/PowHegHooks.h, and is further described on a separate page. A user example is found in examples/main31.
• The other traditional approach for NLO calculations is the MC@NLO one [Fri02]. In it the shower emission probability, without its Sudakov factor, is subtracted from the real-emission matrix element to regularize divergences. It therefore requires a analytic knowledge of the way the shower populates phase space. The aMC@NLO package [Fre11] offers an implementation for PYTHIA 8, developed by Paolo Torrielli and Stefano Frixione. The global-recoil option of the PYTHIA final-state shower has been constructed to be used for the above-mentioned subtraction.
• Multi-jet merging in the CKKW-L approach [Lon01] is directly available. Its implementation, relevant parameters and test programs are documented on a separate page.
• Multi-jet matching in the MLM approach [Man02, Man07] is also available, either based on the ALPGEN or on the Madgraph variant, and with input events either from ALPGEN or from Madgraph. For details see separate page.
• Unitarised matrix element + parton shower merging (UMEPS) is directly available. Its implementation, relevant parameters and test programs are documented on a separate page.
• Next-to-leading order multi-jet merging (in the NL3 and UNLOPS approaches) is directly available. Its implementation, relevant parameters and test programs are documented on a separate page.
• Next-to-leading order jet matching in the FxFx approach is also available. For details see separate page.

MC@NLO, jet matching, multi-jet merging and NLO merging with main89.cc

All settings can be transferred to main89.cc through an input file. The input file is part of the command line input of main89.cc, i.e. you can execute main89 with the command

./main89 myInputFile.cmnd myhepmc.hepmc

to read the input myInputFile.cmnd and produce the output file myhepmc.hepmc . Since main89.cc is currently a "front-end" for different types of matching/merging, we will briefly discuss the inputs for this sample program in the following.

Inputs

All input settings are handed to main89.cc in the form of an input file. We have included the input settings files

         main89mlm.cmnd, which illustrates the MLM jet matching interface,

         main89ckkwl.cmnd, which illustrates the CKKW-L multi-jet merging interface,

         main89umeps.cmnd, which illustrates the UMEPS multi-jet merging interface, and

         main89fxfx.cmnd, which illustrates the FxFx NLO jet matching interface,

         main89unlops.cmnd, which illustrates the UNLOPS multi-jet NLO merging interface.

Other settings (e.g. using main89.cc as simple LO+PS or as MC@NLO interface) are of course possible. In the following, we will briefly explain how input for the five choices above are generated and handled.

MLM jet matching with main89.cc

CKKW-L merging with main89.cc

UMEPS merging with main89.cc

FxFx (NLO) jet matching with main89.cc

UNLOPS (NLO) merging with main89.cc

Implementing an external ME+PS combination scheme and interfacing this plugin with Pythia

To understand how to design a MM plugin for Pythia, it is useful to review how Pythia's internal merging machinery is structured. The interaction between the core Pythia and the merging code is governed by the Merging and MergingHooks classes. Note that for moderately complex requirements, it may be sufficient to only replace Pythia's instance of MergingHooks with a pointer to an external class (cf. CKKW-L merging). The latter two classes are supplemented with the helper classes History and HardProcess. The latter gathers information on the (user-supplied information about the) hard core scattering process to which hard jets are added by ME+PS merging. It is only used as a helper to the MergingHooks class. The History class contains the implementation of all internal (LO or NLO) merging schemes. The Merging class acts as a bridge between the implementation in the History class and the rest of the Pythia code.

To implement an external MM plugin, you will have to write classes that derive from the Merging, MergingHooks and HardProcess classes of Pythia. For special cases, it might also be permissible to only implement a replacement of the Merging class, while still using Pythia's implementation of the other two classes. The external MM plugin can then be transferred to and used by Pythia much in the same way as UserHooks classes or shower plugins. More concretely, an external MM code will be used if a pointer to an instance of the external classes is transferred to Pythia via the methods

Pythia::setMergingPtr( Merging* myMerging)  

Pythia::setMergingHooksPtr( MergingHooks* myMergingHooks)  

MergingHooks::setHardProcessPtr( HardProcess* myHardProcess)  

The option to only use a user-defined MergingHooks instance is already documented in the item CKKW-L merging and will not be discussed further. We will now focus on how to implement external Merging, MergingHooks and HardProcess classes that can be used as a complete replacement of the Pythia methods. Let us assume that you want to create a class of type MyMerging, and you call its instance myMerging. For this external ME+PS merging class to be interfaced to Pythia, the class needs to inherit from the Pythia8::Merging base class. It is further necessary to define the following functions that serve as interface to Pythia:

virtual ~MyMerging()  
A destructor for your ME+PS class. If not defined, the base class's empty destructor will be used.

virtual void MyMerging::init()  
A method that is used to initialize your merging class. Pythia will call this function during its initialization and after all pointers to internal classes (e.g. to instances of the Info and ParticleData classes) have been set up.

virtual void statistics()  
This function can be used to collect and print merging information at the end of the event generation. Pythia will call this function in the execution of a Pythia::stat() call.

virtual int MyMerging::mergeProcess( Event& process)  
This function should be the main interface of Pythia to the MM plugin. Pythia will execute this function once the partonic (fixed-order) scattering has been constructed (or read from LHEF). The partonic scattering is transferred via the process argument. The external MM plugin should then, based on the process, implement the matching/merging strategy. It is permissible that this function changes process. In this case, Pythia will continue the event generation with the changed process as starting point. The return value of the function steers how Pythia should proceed after the function execution. The following return values are supported:

For more details on how to design your MyMerging class, and to understand the interface to Pythia, studying Pythia's internal code is unavoidable. Each potential developer of a MM plugin should do so.

The other main ingredient of the interface to MM plugins is a new implementation of the MergingHooks class. Let us assume that you want to create a class of type MyMergingHooks, and you call its instance myMergingHooks. For this class to be interfaced to Pythia, it will need to inherit from the Pythia8::MergingHooks base class.

virtual ~MyMergingHooks()  
A destructor for your MergingHooks class. If not defined, the base class's empty destructor will be used.

virtual void MyMergingHooks::init()  
A method that is used to initialize your MyMergingHooks class. Pythia will call this function during its initialization and after all pointers to internal classes (e.g. to instances of the Info and ParticleData classes) have been set up.

virtual bool MyMergingHooks::canVetoStep()  
This function will be used to tell Pythia if a CKKW-L-style event veto after the first parton shower emission should be checked. If so, the function should return true, and false otherwise.

virtual bool MyMergingHooks::doVetoStep( const Event& process, const Event& event, bool doResonance = false )  
This function will be used to implement the check of a CKKW-L-style event veto after the first parton shower emission, i.e. to check if the first parton shower emission is above the merging scale. If the input event event after emission should be kept, then false should be returned. If you want instead to veto the event and continue with a completely now hard scattering event, true should be returned.

virtual bool MyMergingHooks::canVetoEmission()  
This function will be used to tell Pythia if a veto of emissions should potentially be applied.

virtual bool MyMergingHooks::doVetoStep( const Event& event)  
This function will be used to implement the check if shower emissions should be discarded, as e.g. necessary in UMEPS or UNLOPS merging. You can study the input event event after emission, and return true if the emission is valid, and false if you want to reject the emission. Note that this veto does not lead to event rejections, only in potentially removing certain emissions during shower evolution.

virtual bool MyMergingHooks::setShowerStartingScales( bool isTrial, bool doMergeFirstEmm, double& pTscaleIn, const Event& event, double& pTmaxFSRIn, bool& limitPTmaxFSRin, double& pTmaxISRIn, bool& limitPTmaxISRin, double& pTmaxMPIIn, bool& limitPTmaxMPIin )  
This function allows to set the starting scales for timelike and spacelike showering as well as multiparton interactions. It is thus necessary to properly start trial showers (that generate necessary no-emission probabilities), and for setting the correct starting conditions for parton showering of accepted (non-zero weight) events. The input event gives the hard process before showers and MPI are attempted. If isTrial=true, this means that the function is currently called from within a trial shower object (to produce no-emission probabilities). If doMergeFirstEmm=true, then the function is called to set starting conditions for the shower evolution of an (accepted) event. The double arguments pTscaleIn, pTmaxFSRIn, pTmaxISRIn and pTmaxMPIIn are tentative values for the starting scales of FSR, ISR and MPI. The function may overwrite these with the desired values. Similarly, limitPTmaxFSRin, limitPTmaxFSRin and limitPTmaxMPIin inform Pythia if the phase space for FSR/ISR/MPI is restricted (true) or unrestricted (false). Again, the tentative values can be overwritten.

The MergingHooks base class allows for further virtual functions that are not directly called by Pythia, and are hence not necessary to define. Th usage of these functions within Pythia's Merging and History classes is documented in CKKW-L merging. The additional (optional) virtual functions are:

virtual double dampenIfFailCuts( const Event& inEvent )  

virtual bool canCutOnRecState()  

virtual bool doCutOnRecState( const Event& event )  

virtual bool canVetoTrialEmission()  

virtual bool doVetoTrialEmission( const Event&, const Event& )  

virtual double hardProcessME( const Event& inEvent )  

virtual double MyMergingHooks::tmsDefinition( const Event& event)  

virtual int MyMergingHooks::getNumberOfClusteringSteps(const Event& event, bool resetNjetMax = false)  

virtual bool useShowerPlugin()  

The internal implementation of MergingHooks in Pythia heavily relies on the HardProcess helper class. It is in principle not necessary to follow the same strategy when implementing a derived MyMergingHooks class. However, to benefit from the Pythia implementation, and to allow for a structure similar to the internal code also for an external MM plugin, it is also possible to effectively replace (in the MergingHooks class) the pointer to an instance of HardProcess with a pointer to an external implementation. Let us assume that you want to create a class of type MyHardProcess, and you call its instance myHardProcess. For this class to be interfaced to MergingHooks (or the derived MyMergingHooks class), it will need to inherit from the Pythia8::HardProcess base class.

virtual ~MyHardProcess()  
A destructor for your HardProcess class. If not defined, the base class's empty destructor will be used.

virtual void MyHardProcess::initOnProcess( string process, ParticleData* particleData)  
This function can be used to initialize the instance of your HardProcess class. In the internal Pythia implementation, this acts as a wrapper around the next function.

virtual void MyHardProcess::translateProcessString( string process)  
This function will use the string argument to set up the hard process bookkeeping, e.g. how many incoming/outgoing particles of which flavour are contained in the core (lowest multiplicity) scattering process.

virtual void MyHardProcess::storeCandidates( const Event& event, string process)  
This function studies the input event and book-keeps the particles that may be considered as part of the core scattering process. For this, it may use the four next functions.

virtual bool MyHardProcess::allowCandidates(int iPos, vector<int> Pos1, vector<int> Pos2, const Event& event)  
This function uses the input vectors of positions of particles in the input event to decide if the particle with iPos could be member of the core scattering. If the particle with position iPos cannot be part of the core scattering (e.g. because it is a final state parton, while the core scattering contains final state leptons only), then the function should return false. Else, return true to allow this candidate. Note that it might be possible to find multiple equally good core scattering candidates. In this case, all candidates should be found (with the findOtherCandidates function), and can be potentially be replaced (with exchangeCandidates).

virtual bool MyHardProcess::matchesAnyOutgoing(int iPos, const Event& event)  
This function may be used to check if the particle with position iPos in the input event should be considered an outgoing particle of the core scattering.

virtual bool MyHardProcess::findOtherCandidates(int iPos, const Event& event, bool doReplace)  
The argument iPos specifies the position of a particle in the input event which is tagged as part of the core scattering. This function may be used to check the role of iPos as core scattering member may be filled by another particle in the event record. If so, and if doReplace=true, then iPos will no longer be book-kept as part of the core scattering. An example where this functionality is helpful is if the input event is g g -> b b~ b b~, and the core scattering is g g -> b b~. Not swapping the hard process candidates could in this case mean that not all parton shower histories can be found. The function should return false if no replacements can be found, and true otherwise.

virtual bool MyHardProcess::exchangeCandidates( vector<int> candidates1, vector<int> candidates2, map<int, int> further1, map<int, int> further2)  
This function implements the replacement of a list of core scattering candidates by another list of candidates.