The first example of section
may help to clarify
what is going on. When PY2ENT is called to generate a
pair, the quarks are stored in lines 1 and 2 of the event record,
respectively. Colour information is set to show that they belong
together as a colour singlet. The counter N is also updated
to the value of 2. At no stage is a previously generated event
removed. Lines 1 and 2 are overwritten, but lines 3
onwards still contain whatever may have been there before. This does
not matter, since N indicates where the `real' record ends.
As PYEXEC is called, explicitly by you or indirectly
by PY2ENT, the first entry is considered and found to be
the first parton of a system. Therefore the second entry is also found,
and these two together form a colour singlet parton system, which may
be allowed to fragment. The `string' that fragments is put in line 3
and the fragmentation products in lines 4 through 10 (in this
particular case). At the same time, the
and
in the
first two lines are marked as having fragmented, and the same for
the string. At this stage, N is 10. Internally in PYEXEC
there is another counter with the value 2, which indicates how far
down in the record the event has been studied.
This second counter is gradually increased by one. If the entry in
the corresponding line can fragment or decay, then fragmentation or
decay is performed.
The fragmentation/decay products are added at the end of the event
record, and N is updated accordingly. The entry is then also
marked as having been treated. For instance, when line 3 is
considered, the `string' entry of this line is seen to have been
fragmented,
and no action is taken. Line 4, a
, is allowed to decay to
; the decay products are stored in lines 11 and 12,
and line 4 is marked as having decayed. Next, entry 5 is allowed to
decay. The entry in line 6,
, is a stable particle (by
default) and is therefore passed by without any action being taken.
In the beginning of the process, entries are usually unstable, and N grows faster than the second counter of treated entries. Later on, an increasing fraction of the entries are stable end products, and the rôles are now reversed, with the second counter growing faster. When the two coincide, the end of the record has been reached, and the process can be stopped. All unstable objects have now been allowed to fragment or decay. They are still present in the record, so as to simplify the tracing of the history.
Notice that PYEXEC could well be called a second time.
The second counter would then start all over from the beginning, but
slide through until the end without causing any action, since
all objects that can be treated already have been.
Unless some of the relevant switches were changed meanwhile, that
is. For instance, if
decays were switched off the first time
around but on the second, all the
's found in the record
would be allowed to decay in the second call. A particle once
decayed is not `undecayed', however, so if the
is put back
stable and PYEXEC is called a third time, nothing will happen.