THE EGS5 CODE SYSTEM

2.6 General Implementation Notes
We have seen in the preceding sections how it is possible, given the total cross sections, branching
ratios, final state joint density functions, and an endless supply of random numbers, to simulate
coupled electron and photon transport. Because of the statistical nature of the Monte Carlo method,
the uncertainty in the results will depend on the number of histories run. Generally, statistical
uncertainties are proportional to the inverse square root of the number of histories[156]. Thus, to
decrease uncertainties by half it is necessary to run four times as many histories. Also, for given
cutoff energies, the CPU time required to simulate a shower history is in general slightly more than
linear in the energy of the incident particle. Because of all of these factors, low-uncertainty Monte
Carlo calculations of high-energy shower simulations can be very time consuming.
The most effective way to ease the computational effort of a Monte Carlo simulation is to
minimize the number of calculations required at the deepest levels inside the particle transport
loops by precomputing the values of as many of the required variables as possible. It is for this
reason that the computational task of almost all Monte Carlo programs is divided into two parts.
First, a preprocessor code (PEGS, for the EGS5 code system) uses theoretical (and sometimes
empirical) formulas to compute the various physical quantities needed and prepares them in a form
for fast numerical evaluation. A second code (EGS itself, in this work) then uses this data, along
with user-supplied subroutines which describe the problem geometry and control the scoring of
results, to perform the actual simulation. The motivation is to perform in advance (in PEGS)
as much computation as possible, so that amount of work done during actual particle transport
simulation is minimized. In earlier versions of EGS, PEGS was a stand-alone program, because with
the slower CPUs in previous generation computers, the data preparation burdens were sometimes
on the same scale as simulation times. As faster computers have become available, users have
typically applied them to longer simulations, and the ratio of data-preparation time to simulation
time has shrunk dramatically. Therefore, beginning with EGS5, PEGS, has been an embedded as
subroutine which can be called by EGS5 user code at the beginning of each simulation.
To aid in debugging and to help those interested in studying the various physics processes
modeled in EGS, starting with EGS4, the EGS Code System was expanded beyond the minimum
coding necessary to simulate radiation transport. With this in mind, PEGS was written in a
modular form, and now contains almost 100 subprograms. These include functions to evaluate
physical quantities which are either needed by PEGS or are of interest for other reasons. Other
routines necessary for use of PEGS within EGS5 include fitting routines and routines to write the
data for a given material onto a data file. Included among the PEGS subprograms not needed for
the operation of EGS5 itself are routines to plot the functions on a lineprinter or a graphic device,
and a routine to compare (on a lineprinter plot) the theoretical final state density functions with
sampled final state distributions. Even though PEGS is now a subroutine in the overall EGS5
package, all of the plotting and density function computation routines have been preserved, and
may be accessed by appropriate user code.
The new PEGS driving subroutine, PEGS5, calls some once-only initialization routines and then
enters an option loop. After reading in the option that is desired, a NAMELIST read establishes other
30