In high-luminosity colliders, there is a non-negligible probability that one single bunch crossing may produce several separate events, so-called pile-up events. This in particular applies to future colliders like LHC, but one could also consider e.g. colliders with high rates of collisions. The program therefore contains an option, currently only applicable to hadron-hadron collisions, wherein several events may be generated and put one after the other in the event record, to simulate the full amount of particle production a detector might be facing.
The program needs to know the assumed luminosity per bunch-bunch crossing, expressed in mb. Multiplied by the cross section for pile-up processes studied, , this gives the average number of collisions per beam crossing, . These pile-up events are taken to be of the minimum-bias type, with diffractive and elastic events included or not (and a further subdivision of diffractive events into single and double). This means that may be either , or . Which option to choose depends on the detector: most detectors would not be able to observe elastic scattering, and therefore it would be superfluous to generate that kind of events. In addition, we allow for the possibility that one interaction may be of a rare kind, selected freely by you. There is no option to generate two `rare' events in the same crossing; normally the likelihood for that kind of occurrences should be small.
If only minimum-bias type events are generated, i.e. if only one cross section is involved in the problem, then the number of events in a crossing is distributed according to a Poisson with the average number as calculated above. The program actually will simulate only those beam crossings where at least one event occurs, i.e. not consider the fraction of zero-event crossings. Therefore the actually generated average number of pile-up events is .
Now instead consider the other extreme, where one event is supposed
be rare, with a cross section
The probability that a bunch crossing will give events, whereof
one of the rare kind, now is
Clearly, for processes with intermediate cross sections, , also the average number of events will be intermediate, and it is not allowed to assume only one event to be of the `rare' type. We do not consider that kind of situations.
Each pileup event can be assigned a separate collision vertex within the envelope provided by the colliding beams, see MSTP(151). Only simple Gaussian shapes in space and time are implemented internally, however. If this is too restrictive, you would have to assign interaction points yourself, and then shift each event separately by the required amount in space and time.
When the pile-up option is used, one main limitation is that event records may become very large when several events are put one after the other, so that the space limit in the PYJETS common block is reached. It is possible to expand the dimension of the common block, see MSTU(4) and MSTU(5), but only up to about 20000 entries, which may not always be enough, especially not for LHC. Simplifications like switching off decay may help keep down the size, but also has its limits.
For practical reasons, the program will only allow an up to 120. The multiplicity distribution is truncated above 200, or when the probability for a multiplicity has fallen below , whichever occurs sooner. Also low multiplicities with probabilities below are truncated.