Tunes

Technically, PYTHIA parameters can be varied independently of each other, but the physical requirement of a sensible description of a set of data leads to correlations and anticorrelations between the parameters. Hence the need to produce tunes, not of one parameter at a time, but simultaneously for a group of them. A well-known (separate) such example is parton densities, where combined tunes to a wide range of data have been produced, that can then be obtained prepackaged.

Given the many PYTHIA parameters to be tuned, it is convenient to divide the task into subtasks. Firstly, if we assume jet universality, hadronization and final-state parton showers should be tuned to e^+e^- annihilation data, notably from LEP1, since this offers the cleanest environment. Secondly, with such parameters fixed, hadron collider data should be studied to pin down multiparton interactions and other further aspects, such as initial-state radiation. Ideally this would be done separately for diffractive and non-diffractive events, although it is not possible to have a clean separation. (Thirdly would come anything else, such as physics with photon beams, which involve further parameters, but that is beyond the current scope.)

The first step was taken, with a tune to LEP1 data by Hendrik Hoeth, using the Rivet + Professor framework. Starting with version 8.125 it defined the default values for hadronization parameters and timelike showers.

The situation is more complicated for hadronic interactions in general and multiparton interactions in particular, where PYTHIA 8 is more different from PYTHIA 6, and therefore more work is needed. Specifically, it is not possible to "port" a PYTHIA 6 tune to PYTHIA 8.

A first simple tune, appropriately called "Tune 1", became default starting with version 8.127. It was noted, in particular by Hendrik Hoeth, that this tune had a tension between parameters needed to describe minimum-bias and underlying-event activity. Therefore some further physics features were introduced in the code itself [Cor10a], which were made default as of 8.140. This version also included two new tunes, 2C and 2M, based on the CTEQ 6L1 and the MRST LO** PDF sets, respectively. These have been made by hand, as a prequel to complete Professor-style tunings.

The very first data to come out of the LHC showed a higher rapidity plateau than predicted for current PYTHIA 6 tunes, also for the lower energies. This may suggest some tension in the data. Two alternatives, 3C and 3M, were produced by a few brute-force changes of 2C and 2M. These were introduced in 8.140, but discontinued in 8.145 in favour of the newer 4C tune, that is based on a more serious study of some early LHC data, see [Cor10a]. Following the comparative studies in [Buc11], which independently confirmed a reasonable agreement with LHC data, tune 4C was made the default from 8.150. A variant is tune 4Cx, where the Gaussian matter profile has an x-dependent width [Cor11].

Tune 4C was the basis for many subsequent LHC tunes. Several ATLAS tunes have been included here, obtained with different PDFs and with different emphasis on minimum-bias and underlying-event data [ATL12]. These typically require LHAPDF to be linked, but this can be avoided in cases where the same PDF set is implemented internally. Also two CMS underlying-event tunes are implemented [CMS14]. The ATLAS AZ tune [ATL14] instead puts emphasis on the pT spectrum of the Z^/gamma^*0 boson.

The Monash 2013 tune [Ska14] is based on a larger set of LHC distributions. It starts out from a more careful comparison with and tuning to LEP data, and so involves several parameter changes. The PDF used is the NNPDF2.3 QCD+QED LO one with alpha_s(M_Z) = 0.130, which includes more recent data than used in the previous default, and opens up for processes with incoming photons to the hard process. It is the default starting from 8.200.

Recent tunes by the LHC collaborations are based on the Monash 2013 one. This includes the CMS tune MonashStar, or formally CUETP8M1-NNPDF2.3LO (currently unpublished). More significantly, ATLAS has produced and published a whole family for underlying-event tunes based on a major effort, including simultaneous fits of ten parameters [ATL14a]. This includes four central tunes, with four different PDF sets, and ten variations around the NNPDF2.3 QCD+QED LO central tune, grouped in five pairs of variations up and down. The publication [ATL14a] should be consulted for further details, like with what additional settings various processes have been generated, which should be respected to reap full benefit of the tunes.

Central diffraction is a recent addition to the "soft QCD" process palette, and is thus not yet included in tunes; indeed its cross section is actively zeroed. You can switch it back on after you have selected your tune, with SigmaTotal:zeroAXB = off. But note that, since the total cross section is assumed unchanged, the nondiffractive cross section is reduced and thus also the MPI machinery affected, even if effects should not be big (for a small central diffractive cross section).

Note that comparisons with data also require that other aspects agree, such as that decay chains are stopped at an agreed-on level. For instance, in the ATLAS tunes all particles with a lifetime above 10 mm are considered stable, ParticleDecays:limitTau0 = on, ParticleDecays:tau0Max = 10. We have chosen not to include this as part of the tune settings itself, since the tune as such could still be used with any other choice of stable and unstable particles.

Further comparisons have been posted on the MCPLOTS pages. They have been produced with help of the Rivet package [Buc10].

To simplify comparisons for the user, we propose to collect some of the tunes here, in a prepackaged form. Of course, in all cases it is a matter of setting values for parameters already defined elsewhere, so the tunes offer no new functionality, only a more convenient setup.

You should be aware that the evolution of the program will not guarantee complete backwards compatibility between versions. Most obviously this concerns bug fixes. But also for some other major changes, like the introduction of the new diffractive machinery, the default behaviour of old tunes has been changed retroactively. (Which should be fine for diffraction, since previous tunes were not based on data strongly influenced by diffraction.)

The setup of the tunes is special, in that the choice of a tune forces the change of several different flags, modes and parameters. Furthermore a design principle has been that it should be possible to start out from a tune and then change a few of its settings. This gives power and flexibility at the expense of requiring a more careful ordering of commands. We therefore here sketch the order in which operations are carried out.

1. The constructor of a Pythia instance will read in all settings, and initialize them with their default values.
2. At the end of this operation, the Tune:ee and Tune:pp modes (see further below) are checked. If either of them are positive the methods Settings::initTuneEE(...) and Settings::initTunePP(...), respectively, are called to overwrite the whole collection of settings in the relevant tune. Zero (or negative) means that nothing will be done. Since most pp/ppbar tunes have been made in the context of an e^+e^- one, initTunePP(...) usually calls initTuneEE(...) to provide this synchronization.
3. After the Pythia constructor all the relevant values for the default tune(s) have thus been set up.
4. You as a user can now start to overwrite the values at will, using Pythia::readFile(...) to read a configuration file, or a list of Pythia::readString(...) commands, or the lower-level Settings methods. All changes are made in the order in which the commands are encountered during the execution. A given variable can be changed multiple times, but it is the latest change that sets the current value.
5. The two Tune:ee and Tune:pp modes can also be changed in exactly the same way as described for all other settings above. Unique for them, however, is that when one of them is encountered it also initiates a call to the initTuneEE(...) or initTunePP(...) method, respectively. In such cases all settings affected by the e^+e^- or pp/ppbar tune are first reset to the default values (the -1 options) and thereafter the relevant tune is set up. Recall that initTunePP(...) in its turn is allowed to call initTuneEE(...).
6. It is possible to mix commands of type 4 and 5 in any order; it is always the last change that counts. That is, any changes you have made to variables of a tune before a Tune:ee or Tune:pp command are overwritten by it, while variables you set after will overwrite the tune values. Further, the Tune:pp command usually implies an e^+e^- tune as well. Therefore Tune:ee would rarely be used for LHC applications. As a rule, instead, you want to begin with the Tune:pp choice, and thereafter modify only a small part of its settings.
7. Needless to say, the flexibility can lead to unwanted setups if you do not exercise some discipline. It is therefore recommended that you always check the listing obtained with Pythia::settings.listChanged() to confirm that the final set of changes is the intended one.