University of Canterbury Department of Computer Science and Software Engineering

Project Akaroa

COSC home

Akaroa2© - Architecture and Implementation

Akaroa2© is designed for running quantitative stochastic discrete-event simulations on Unix multiprocessor systems or networks of heterogeneous Unix workstations. It is written in the dialect of C++ accepted by the GNU g++ compiler and will run on any Unix system supporting Berkely-style sockets for interprocess communication. A shared file system is preferable but not strictly necessary.

Sequential simulation programs to be run under Akaroa2© must be implemented in a language capable of calling library routines written in C.

1. Programming Interface

This section describes the essential features of the interface between the user's simulation program and the Akaroa2© system. Some details have been omitted; see the Akaroa2© User's Manual for a full description.

The current version of Akaroa2© can be used to estimate mean values only, although probabilites can be estimated from the mean of a sequence of values in the range {0,1}.

In the case where a single performance measure, or parameter, of the system being studied is to be analysed, each time the simulation generates an observation x of the parameter, it makes the call


Akaroa2© automatically collects the observations, calculates their mean value, estimates the variance of the mean, and derives a confidence interval at a given confidence level. When the relative half-width of the confidence interval is less than or equal to the precision requested for the estimate of the parameter, Akaroa2©automatically terminates the simulation and reports the results to the user.

If more than one parameter is being analysed, the simulation must first call


to indicate that n parameters are to be analysed, and then for each observation call

AkObservation(i, x)

where i is a number from 1 to n identifying the parameter. Akaroa2© stops the simulation only when the estimates of all parameters being analysed have reached their requested precisions.

After compiling and linking with the Akaroa2© library, the same program can be used in two ways: stand-alone, or under Akaroa2©. Running the program in stand-alone mode is useful for debugging purposes, since diagnostic output may be written, the program may be run under a debugger, or any of the usual debugging techniques used, without Akaroa2's parallel execution machinery getting in the way.

Once debugged, multiple simulation engines (instances of the simulation program) may be launched in parallel using the akrun command. The user specifies how many engines are required; Akaroa2© automatically launches the necessary processes, collects the observations from each simulation engine and combines them into a single global estimate for each parameter. Akaroa2© terminates all the simulation engines when the global estimates have all reached their required precisions.

2. Structure of a Simulation Engine

Figure 1 shows the structure of a simulation program, and the flow of data when the program is run stand-alone. On startup, the Akaroa2© library routines look for an Akaroa2© environment file. If present, this file can be used to specify various options which control the operation of Akaroa2©, such as the maximum precision and the confidence level required for each parameter, and the method used to estimate the variance of the estimates.

When AkObservation is called, the observation is routed to an observation analyser, of which there is one for each analysed parameter. The observation analyser is initially in a transient mode in which it applies various heuristic and statistical tests to determine whether the simulation has left the transient stage and entered a steady state. Then the analyser enters steady state mode, in which it keeps track of the mean and its current variance and precision.

After passing the observation to the analyser, AkObservation tests whether the precisions estimated by all observation analysers have reached those requested. If so, a report for each parameter is written to standard output, and the progam terminated.

Figure 1 - Simulation engine running stand-alone.

3. Structure of the Akaroa2© System

Before a simulation can be run in parallel under Akaroa2©, it is necessary to start the system up. This is done by starting an akmaster process, and then an akslave process on each host where simulation engines are to be run. On startup, each akslave establishes a connection with the akmaster, giving the process structure illustrated in Figure 2.

Figure 2 - Akaroa2© 2 process structure with akslave processes on three hosts.

The akrun command is used to start a simulation. The arguments to akrun indicate what simulation program to run, how many simulation engines should be launched, and possibly other options. The akrun process contacts the akmaster and sends it this information. It also reads the environment file, if any, and passes its contents to the akmaster. The akmaster creates a simulation manager to coordinate activity related to this simulation. The simulation manager chooses the requested number of akslave processes and tells each one to launch an instance of the simulation program. These steps are illustrated in Figure 3.

Figure 3 - Launching simulation engines

Each akslave launches an instance of the simulation program on its respective host, and passes it the address of the akmaster process. The simulation engine connects to the akmaster, which associates the connection with the appropriate simulation manager. The simulation engine generates observations which are collected by local analysers within the engine.

Periodically during the simulation, each local analyser reports its current local estimate to a corresponding global analyser in the simulation manager. The global analyser combines the local estimates of the parameter concerned from each simulation engine, and calculates a global estimate of the parameter. This phase is illustrated in Figure 4.

Figure 4 - Simulation running

The simulation manager monitors the global estimates of all the parameters, and when they have all reached the required precision, it tells all the simulation engines to terminate, breaks their connections, and sends the final global estimates back to the akrun process. The akrun then writes a report to standard output and exits. This final step is shown in Figure 5.

Figure 5 - Reporting results


Last modified:  23 Jun 2013