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
much smaller
than
, i.e.
.
The probability that a bunch crossing will give
events, whereof
one of the rare kind, now is
![]() |
(229) |
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 might not always be enough, e.g. 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 a
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.