The HEPEVT Standard

A set of common blocks was developed and agreed on within the framework of the 1989 LEP physics study, see [Sjö89]. This standard defines an event record structure which should make the interfacing of different event generators much simpler.

It would be a major work to rewrite PYTHIA to agree with this standard event record structure. More importantly, the standard only covers quantities which can be defined unambiguously, i.e. which are independent of the particular program used. There are thus no provisions for the need for colour-flow information in models based on string fragmentation, etc., so the standard common blocks would anyway have to be supplemented with additional event information. For the moment, the adopted approach is therefore to retain the PYJETS event record, but supply a routine PYHEPC which can convert to or from the standard event record. Owing to a somewhat different content in the two records, some ambiguities do exist in the translation procedure. PYHEPC has therefore to be used with some judgement.

In this section, the standard event structure is first presented, i.e. the most important points in [Sjö89] are recapitulated. Thereafter the conversion routine is described, with particular attention to ambiguities and limitations.

The standard event record is stored in two common blocks. The second of these is specifically intended for spin information. Since PYTHIA never (explicitly) makes use of spin information, this latter common block is not addressed here. A third common block for colour flow information has been discussed, but never formalized. Note that a CALL PYLIST(5) can be used to obtain a simple listing of the more interesting information in the event record.

In order to make the components of the standard more distinguishable in your programs, the three characters HEP (for High Energy Physics) have been chosen to be a part of all names.

Originally it was not specified whether real variables should be in single or double precision. At the time, this meant that single precision became the default choice, but since then the trend has been towards increasing precision. In connection with the 1995 LEP 2 workshop, it was therefore agreed to adopt DOUBLE PRECISION real variables as part of the standard, and also to extend the size from 2000 to 4000 entries [Kno96]. If, for some reason, one would want to revert to single precision, this would only require trivial changes to the code of the PYHEPC conversion routine described below.

Purpose:

to contain an event record in a Monte Carlo-independent format.

NMXHEP:

maximum numbers of entries (particles) that can be stored in the common block. The default value of 4000 can be changed via the parameter construction. In the translation, it is checked that this value is not exceeded.

NEVHEP:

is normally the event number, but may have special meanings, according to the description below:

> 0 :

event number, sequentially increased by 1 for each call to the main event generation routine, starting with 1 for the first event generated.

= 0 :

for a program which does not keep track of event numbers, as some of the PYTHIA routines.

= -1 :

special initialization record; not used by PYTHIA.

= -2 :

special final record; not used by PYTHIA.

NHEP:

the actual number of entries stored in the current event. These are found in the first NHEP positions of the respective arrays below. Index IHEP, 1$\leq$IHEP$\leq$NHEP, is used below to denote a given entry.

ISTHEP(IHEP):

status code for entry IHEP, with the following meanings:

= 0 :

null entry.

= 1 :

an existing entry, which has not decayed or fragmented. This is the main class of entries, which represents the `final state' given by the generator.

= 2 :

an entry which has decayed or fragmented and is therefore not appearing in the final state, but is retained for event history information.

= 3 :

a documentation line, defined separately from the event history. This could include the two incoming reacting particles, etc.

= 4 - 10 :

undefined, but reserved for future standards.

= 11 - 200 :

at the disposal of each model builder for constructs specific to his program, but equivalent to a null line in the context of any other program.

= 201 - :

at the disposal of users, in particular for event tracking in the detector.

IDHEP(IHEP) :

particle identity, according to the PDG standard. The four additional codes 91-94 have been introduced to make the event history more legible, see section and the MSTU(16) description of how daughters can point back to them.

JMOHEP(1,IHEP) :

pointer to the position where the mother is stored. The value is 0 for initial entries.

JMOHEP(2,IHEP) :

pointer to position of second mother. Normally only one mother exists, in which case the value 0 is to be used. In PYTHIA, entries with codes 91-94 are the only ones to have two mothers. The flavour contents of these objects, as well as details of momentum sharing, have to be found by looking at the mother partons, i.e. the two partons in positions JMOHEP(1,IHEP) and JMOHEP(2,IHEP) for a cluster or a shower system, and the range JMOHEP(1,IHEP)-JMOHEP(2,IHEP) for a string or an independent fragmentation parton system.

JDAHEP(1,IHEP) :

pointer to the position of the first daughter. If an entry has not decayed, this is 0.

JDAHEP(2,IHEP) :

pointer to the position of the last daughter. If an entry has not decayed, this is 0. It is assumed that daughters are stored sequentially, so that the whole range JDAHEP(1,IHEP)-JDAHEP(2,IHEP) contains daughters. This variable should be set also when only one daughter is present, as in $\mathrm{K}^0 \to \mathrm{K}_{\mathrm{S}}^0$ decays, so that looping from the first daughter to the last one works transparently. Normally daughters are stored after mothers, but in backwards evolution of initial-state radiation the opposite may appear, i.e. that mothers are found below the daughters they branch into. Also, the two daughters then need not appear one after the other, but may be separated in the event record.

PHEP(1,IHEP) :

momentum in the $x$ direction, in GeV/$c$.

PHEP(2,IHEP) :

momentum in the $y$ direction, in GeV/$c$.

PHEP(3,IHEP) :

momentum in the $z$ direction, in GeV/$c$.

PHEP(4,IHEP) :

energy, in GeV.

PHEP(5,IHEP) :

mass, in GeV/$c^2$. For space-like partons, it is allowed to use a negative mass, according to PHEP(5,IHEP) $= -\sqrt{-m^2}$.

VHEP(1,IHEP) :

production vertex $x$ position, in mm.

VHEP(2,IHEP) :

production vertex $y$ position, in mm.

VHEP(3,IHEP) :

production vertex $z$ position, in mm.

VHEP(4,IHEP) :

production time, in mm/$c$ ( $\approx 3.33 \times 10^{-12}$ s).

This completes the brief description of the standard. In PYTHIA, the routine PYHEPC is provided as an interface.

Purpose:

to convert between the PYJETS event record and the HEPEVT event record.

MCONV :

direction of conversion.

= 1 :

translates the current PYJETS record into the HEPEVT one, while leaving the original PYJETS one unaffected.

= 2 :

translates the current HEPEVT record into the PYJETS one, while leaving the original HEPEVT one unaffected.

The conversion of momenta is trivial: it is just a matter of exchanging the order of the indices. The vertex information is but little more complicated; the extra fifth component present in PYJETS can be easily reconstructed from other information for particles which have decayed. (Some of the advanced features made possible by this component, such as the possibility to consider decays within expanding spatial volumes in subsequent PYEXEC calls, cannot be used if the record is translated back and forth, however.) Also, the particle codes K(I,2) and IDHEP(I) are identical, since they are both based on the PDG codes.

The remaining, non-trivial areas deal with the status codes and the event history. In moving from PYJETS to HEPEVT, information on colour flow is lost. On the other hand, the position of a second mother, if any, has to be found; this only affects lines with K(I,2)= 91-94. Also, for lines with K(I,1)= 13 or 14, the daughter pointers have to be found. By and large, however, the translation from PYJETS to HEPEVT should cause little problem, and there should never be any need for user intervention. (We assume that PYTHIA is run with the default MSTU(16)=1 mother pointer assignments, otherwise some discrepancies with respect to the proposed standard event history description will be present.)

In moving from HEPEVT to PYJETS, information on a second mother is lost. Any codes IDHEP(I) not equal to 1, 2 or 3 are translated into K(I,1)=0, and so all entries with K(I,1)$\geq 30$ are effectively lost in a translation back and forth. All entries with IDHEP(I)=2 are translated into K(I,1)=11, and so entries of type K(I,1) = 12, 13, 14 or 15 are never found. There is thus no colour-flow information available for partons which have fragmented. For partons with IDHEP(I)=1, i.e. which have not fragmented, an attempt is made to subdivide the partonic system into colour singlets, as required for subsequent string fragmentation. To this end, it is assumed that partons are stored sequentially along strings. Normally, a string would then start at a $\mathrm{q}$ ( $\overline{\mathrm{q}}$) or $\overline{\mathrm{q}}\overline{\mathrm{q}}$ ( $\mathrm{q}\mathrm{q}$) entry, cover a number of intermediate gluons, and end at a $\overline{\mathrm{q}}$ ($\mathrm{q}$) or $\mathrm{q}\mathrm{q}$ ( $\overline{\mathrm{q}}\overline{\mathrm{q}}$) entry. Particles could be interspersed in this list with no adverse effects, i.e. a $\u -\mathrm{g}-\gamma-\overline{\mathrm{u}}$ sequence would be interpreted as a $\u -\mathrm{g}-\overline{\mathrm{u}}$ string plus an additional photon. A closed gluon loop would be assumed to be made up of a sequential listing of the gluons, with the string continuing from the last gluon up back to the first one. Contrary to the previous, open string case, the appearance of any particle but a gluon would therefore signal the end of the gluon loop. For example, a $\mathrm{g}-\mathrm{g}-\mathrm{g}-\mathrm{g}$ sequence would be interpreted as one single four-gluon loop, while a $\mathrm{g}-\mathrm{g}-\gamma-\mathrm{g}-\mathrm{g}$ sequence would be seen as composed of two 2-gluon systems.

If these interpretations, which are not unique, are not to your liking, it is up to you to correct them, e.g. by using PYJOIN to tell exactly which partons should be joined, in which sequence, to give a string. Calls to PYJOIN (or the equivalent) are also necessary if PYSHOW is to be used to have some partons develop a shower.

For practical applications, one should note that $\mathrm{e}^+\mathrm{e}^-$ events, which have been allowed to shower but not to fragment, do have partons arranged in the order assumed above, so that a translation to HEPEVT and back does not destroy the possibility to perform fragmentation by a simple PYEXEC call. Also the hard interactions in hadronic events fulfil this condition, while problems may appear in the multiple interaction scenario, where several closed $\mathrm{g}\mathrm{g}$ loops may appear directly following one another, and thus would be interpreted as a single multigluon loop after translation back and forth.