Hadronization Overview

1. The main fragmentation switch
2. The transition phase
3. The main fragmentation classes
4. Special fragmentation classes
5. Other fragmentation code

The main fragmentation switch

From a user point of view, the main news is a switch between internally implemented fragmentation models. It is put here, so as to make it easily found. Below this, and in linked pages, a more detailed description of the class hierarchy, the physics contents and the free settings will follow.

mode  Fragmentation:model   (default = 0; minimum = 0; maximum = 1)
Selection of main fragmentation model to be used in PYTHIA. (Replaces the functionality previously available through the StringPT:thermalModel switch, but can offer more options in the future.)
option 0 : The standard Lund string fragmentation framework [And83,Sjo84].
option 1 : The alternative thermal string fragmentation framework [Fis16], that uses much of the same string code as above, but have a different approach especially for flavour and transverse momentum selection.

The transition phase

• The beam remnants handling is the step where the remnants of the incoming beams, after a number of partons have been extracted to initiate multiparton interactions (MPIs), are split into a set of partons (and occasionally a hadron) that share the remnant momentum. This sharing is governed by ad-hoc nonperturbative rules.
• Colour reconnection is the notion that the presence of multiple colour charges in an event leads to the possibility for the naive colour topology to be modified, e.g. to configurations with shorter strings. Although defined in terms of parton colour properties, colour reconnection only has a meaning in the context of fragmentation patterns.
• The parton vertex information notably distributes parton in the transverse collision plane, related to hadron or nuclear spatial wave functions, and so is nonperturbative in its nature. This info can be used e.g. to map out the almond-shaped collision region in nucleus-nucleus collisions.

The main fragmentation classes

• FragmentationModel is the top-level class. It is intended that all fragmentation models should derive from this class, even if it is not quite true currently. It does not do anything, but expects the derived class to implement the two main methods init and fragment. It contains pointers to the commonly used StringFlav, StringPT and StringZ, but it is open to you whether to use them.
• LundFragmentation derives from FragmentationModel. It is a small class, organizing the real work to be done in StringFragmentation and MiniStringFragmentation.
• ThermalFragmentation also derives from FragmentationModel, and the code closely follows the one in LundFragmentation. The key difference it that it has its own classes of the StringFlav and StringPT kind.
• StringFragmentation is the main class for handling the fragmentation of a partonic subsystem into a set of primary hadrons. Most of the machinery here cannot easily be changed, but the flexibility comes from the free choice of classes derived from StringFlav, StringPT and StringZ.
• MiniStringFragmentation takes over from StringFragmentation when the mass of the fragmenting system is so small that only one or two hadrons can be produced. It also uses classes derived from StringFlav, StringPT and StringZ, but the latter two only marginally.
• StringFlav handled the selection of a new quark or diquark flavour, and the combination of an old and a new flavour into a hadron. A key aspect of essentially all alternative fragmentation models is that the base class is replaced by a quite different derived one. The StringFlav class is used not only in StringFragmentation and MiniStringFragmentation but also in a few other places, notably in some particle decays.
• StringPT handles the selection of transverse momentum pT in the breakup of a string, assumed to compensate exactly between the quark and antiquark (or diquark-antidiquark) of a break.
• StringZ selects the lightcone energy-momentum fraction z to be taken by a newly produced hadron, out of what remains after previous hadron production. For strings with gluon kinks a more intricate procedure needs to be applied [Sjo84].

Special fragmentation classes

• HiddenValleyFragmentation handles the fragmentation in a hypothetical hidden sector, using the normal StringFragmentation and MiniStringFragmentation classes, but with derived StringFlav, StringPT and StringZ classes. Notably the flavour handling is quite separate from the normal Standard Model one. Many fragmentation parameters are rescaled from the normal values, including some "safety check" cutoffs.
• RHadrons handles the decay of R hadrons, i.e. long-lived particles hypothesized to exist in some Beyond-the-Standard-Model scenarios, such as gluinos, stops and sbottoms. The decays typically are into quarks and gluons, which are handled by the normal shower and string fragmentation methods, but the normal StringFlav and StringZ objects find some use in the RHadrons class.
• LowEnergyProcess is primarily intended for low-energy hadronic rescattering in high-energy collisions, but can also be used for low-energy processes, e.g. as needed in the simulation of the final stages of cosmic-ray cascades. It mainly uses its own dedicated methods for various processes, usually 2→2 and 2→3 ones, but for the higher-energy tail (still only a few GeV) the StringFragmentation and MiniStringFragmentation classes can be used.

Other fragmentation code

• Several methods are in place to allow the user to reweight generated events in the parameters of the fragmentation model. This allows the user to perform fast parameter variation or oversample rare configurations, and reweight to the correct cross section. These methods are documented on the Hadronization Variations page.
• When several strings come close or overlap they may form strings of a higher colour representation, so-called ropes, and/or they may repel each other, so-called shove. A scenario exists for these phenomena, see Rope Hadronization. This scenario could one day be extracted into separate classes, notably for flavour handling, but is currently hardcoded as options or additions inside the normal string fragmentation routines.
• The close-packing scenario is a similar but simpler approach to the one above, again relevant for the case of several nearby strings, and again hardcoded inside the existing routines.
• The space-time evolution of the fragmentation process mirrors the energy-momentum one, with some twists, but by default is not reconstructed. For applications such as hadronic rescattering the hadron production vertices need to be reconstructed, however, and this is then done inside the string fragmentation methods.

Finally, note that the fragmentation routines normally are not called by the user, but as part of the full PYTHIA event generation. The Hadron-Level Standalone page explains how to set up your own partonic configuration and then fragment it.