Introduction

Event evolution uses as its basic data structure vertex and track banks, named MCVX and MCTK respectively. A vertex represents any interaction or boundary transition, and typically has one incident and one or more outgoing tracks. A track represents the propagation of a particle through the detector; it is outgoing at its start vertex and is incident at its end vertex. The data structure consists of a single linear chain of MCVX banks each of which supports a linear chain of outgoing MCTK banks. Each MCTK has a link that points forward to its end vertex.

In the original design, vertices were divided into 4 classes:-

SOURCE

This vertex has no incident track, just one or more outgoing tracks; it represents the initial event captured by the detector.

BOUNDARY

This has one incoming and one outgoing track and represents the transition of a particle through some real or imaginary boundary in the detector.

INTERACTION

This describes some physical particle interaction and has one incident and one or more outgoing tracks.

SINK

This has an incident track but no outgoing tracks and records a particle's ultimate fate.

In SNOMAN 2.08, a 5th class was added:-

PRE_SOURCE

This is one that preceeds a source vertex. For example, if generating electrons from a CC reaction, the electron production vertex is a source vertex which has an incoming neutrino track from a pre_source vertex that describes the reaction that created the neutrino.

This requres a redefinition of a source vertex to one that either has no incident track or whose incident track was produced at a pre_source vertex.

It is the function of MCG_GENERATOR to place in the detector one or more source, and zero or more pre_source vertices, whose type and position are determined by the type of generation required. MCEVLV has the task of evolving the event through space and time until the fate of all particles has been determined.

MCEVLV neither knows nor cares about the detector or the particles being tracked through it; its job is to search through the data structure looking for vertices and tracks that need to be evolved and passing them to VXMAIN or TKMAIN to evolve them. This is achieved in a single pass over the MCVX chain. Starting at the beginning of the chain MCEVLV checks to see if the first MCVX requires evolving, which it will do if it has no outgoing tracks and has not been marked as processed by the SINK vertex processor VXSNK, and if so calls VXMAIN. It next checks all outgoing MCTKs at the MCVX and calls TKMAIN for any that do not have an end vertex. Having completed the first MCVX it repeats the process at the second and all subsequent MCVXs. VXMAIN and TKMAIN will normally generate further MCVX and MCTK banks but will always place them downstream of the current point in the data structure thus ensuring that the single pass over it will not miss them.

VXMAIN has the job of generating all the outgoing tracks at one vertex or, in the case of a sink vertex, calling VXSNK. The routine merely checks the current vertex class and then calls one of VXSRC, VXBOU, VXINT or VXSNK. As currently written, VXSRC is unnecessary; MCG_GENERATOR creates all the outgoing tracks for source vertices so these MCVXs do not need to be evolved. An alternative scheme would be to have MCG_GENERATOR just create the source MCVXs without their outgoing tracks and then leave it to VXSCR to add them. The ascending class hierarchy: source, boundary, interaction, sink is designed to allow class promotion VXSRC, VXBOU and VXINT may all promote the class of the vertex. If an interaction results in the particle being absorbed then it plays no further part in the event. In this case VXINT promotes the class to sink and VXMAIN then passes the MCVX onto VXSNK. Pre_source vertices cannot be promoted.

VXSRC, VXBOU, VXINT and VXSNK provide the interface to the code that deals with the four classes of vertices (pre_source vertices are always dealt with by the generator). Whenever a new track has to be added to the current vertex they directly or indirectly call VXNULL which provides a standardised method of updating the data structure. It lifts a new MCTK bank and copies the contents of the incident MCTK to it (hence VXNULL - the effect of a null vertex). The caller of VXNULL is then free to update the new MCTK as required.

TKMAIN has the job of adding a new end vertex to the current track. It calls GE_NEXT to see how far it is to the next boundary and PHINTL to see how far it is to the next interaction. Armed with this knowledge it knows what happens next to the particle. It calls TKNULL to create a new MCVX bank and then adjusts its contents depending on whether the particle reached the next boundary or interacted.

Recording a complete history of all particle trajectories in the data structure is rather profligate with memory. For most types of events and for reasonable dynamic memory sizes this does not matter but in a few cases, e.g., simulating muon traversals which produce multiple hits on almost every PMT, the memory demands become too large. For these events a facility exists for removing unwanted vertices and tracks. Currently, after processing a vertex and all its tracks, MCEVLV calls VXREMV to remove it if unwanted. To understand this process, consider a vertex A with an outgoing track AB that ends at vertex B. Once vertex B has been processed all its outgoing tracks can be connected to vertex A and the track AB and vertex B can be removed. If this procedure is followed rigorously for all but sink vertices, all that remains are the initial source and pre_source vertices and all tracks incident on their sink vertices. VXREMV does nothing unless enabled by the parameter KILLVX in the MCMA title bank but if enabled it calls VXDELE to perform the data structure update as required.

The removal of unwanted vertices makes clear an important point about the MCVX-MCTK structure. The contents of the MCTK are formally defined to be the track parameters at the point at which the track is incident at its end vertex NOT at its start vertex. Indeed it may only have come indirectly from its start vertex. As is described elsewhere in this document, this is the case for Cerenkov photon vertices created by EGS4. Each time a photon is created the incident electron track is considered to be another outgoing track from a single special EGS4 interaction vertex. Consequently the number of ``tracks" at the EGS4 vertex does not reflect the number of electrons in the shower; only the number of Cerenkov Bundle Vertices produced by the shower.

In 2.04 and earlier versions all Cerenkov photon vertices were generated within EGS4 so that there had to be sufficient memory to hold them all simultaneously. This places a severe memory demand when generating high energy events. In 2.05 onwards each electron step creates a single Cerenkov Bundle Vertex (CBV) and these are not processed until EGS4 returns. Then each bundle is dealt with in turn, unpacking and tracking all its photons. If KILLVX is enabled this ensures that the memory used to track them is recovered ready for the next CBV. The CBVs are automatically deleted after processing, regardless of KILLVX, so that there is no lasting change to the data structure and any user code written to process Cerenkov photon vertices will still work.

The main vertex and track processors have calls to the user routine MCE_USER allowing the user to monitor or modify the evolution process. For more information see the dummy version of mce_user.for in the code directory.