Design Issues Relating to the User Inter face of AKAROA

5.2.1 Development Language and User Interface

Simplicity, space and code eciency, exibility, as well as compatibility with existing sequential simulation programs, were the main considerations when selecting a development language and designing the programming interface for AKAROA. Recognising the naturality of an object-oriented approach in constructing simulation models by means of hierarchically encapsulated classes of objects, AKAROA is written in C++. A user of AKAROA should be required to add only one extra line of code to his/her sequential simulation program before AKAROA transparently transforms it into a parallel simula- tor. Thus, users should not even need to be aware of the existence of multiple (parallel) simulation, precision control, and PSM processes during simulation, since their creation, location (machine and port addresses), co-operation, and inter-machineinterprocess communication, are hidden from users. Binding of simulation processes to various precision control and PSM processes should be performed dynamically, yielding a exible and fault-tolerant system fea- turing totally transparent parallelization from users' point of view, both in the semantic and syntactic sense.

AKAROA's sequential precision control services should be accessed by declaring an object for output data analysis, just like the objects imple- mented for the precision control of estimates in normal sequential simulation (see section 3.1.2 on page 50). Like normal (non-parallel) simulations, the member function responsible for precision control is later called whenever a new observation is generated. The function accepts the value of a new ob- servation as parameter and returns one of two values (i.e. either CONT or STOP) that either orders the simulation to be continued (desired precision of estimates has not been achieved) or to be terminated (all estimates reached the required level of precision). AKAROA's implementation of SA-PTS sim- ulation should be semantically identical to a normal non-parallel simulation; only the type of object that needs to be declared is dierent. The syntax for object declaration and for invoking the object's member functions should be also identical to those in the non-parallel case.

5.2.2 Level of User Involvement

Three unusual aspects of AKAROA'sapplication interface can be summedup in one word: transparency. First, the AKAROA users need not know about the complexities of statistical analysis and precision control when writing a simulator. Major statistical decisions, such as condence levels for esti- mates of various intermediate parameters, signicance levels of statistical tests involved, step sizes between consecutive checkpoints of sequential es- timation, etc., should be made by the designers of the package and oered as reliable (default) values for a given class of typical simulated processes, thereby allowing users to fully focus only on dening the simulated system. Once a user has written a normal simulator, the precision control services of AKAROA can be added by inserting one statement in the program. Second, AKAROAtransparently transforms the resulting (sequential) simulationpro- gram, whether it is written in C, C++, or using AKAROA's BUILD toolkit, into one suited for parallel execution. Thus the user need only program the simulator for running on a classical uniprocessor. Thirdly, AKAROA oers runtime transparency, meaning that the collection of networked workstations is presented to the user as a single virtual uniprocessor, with the sum pro- cessing power of its members. A user runs AKAROA simulations in a similar manner to running any normal (sequential) program. The (parallel) simu- lation process can be started or stopped by the user using PSM commands, just as if they executed on a single machine. As mentioned in section 4.2.2 (on page 74), parallel simulations based on SA-PTS exists as a set of sim- ulation processes (simulation engines) which cooperate with a set of global precision control processes (one for each parameter being estimated). Thus multiple simulation engines need to be created at runtime. When they need to contact a global precision control process that is responsible for the es- timation of a specic parameter, the machine address and port number of that process must be (somehow) located, or one must be created if it does not yet exist. All such aspects of parallel execution, including distributed process creation and management, inter-machine interprocess communica- tion, and distributed termination, are invisible to the user. The desire for runtime transparency can conict with the advantage for providing powerful semantics. For instance, whilst most users would prefer to start parallel sim- ulations in the same manner as sequential (uniprocessor based) runs, more sophisticated users might want to select machines to be used for a given run,

and to specify 'nice' priorities for processes on each of the chosen machines, as well as certain time intervals when some of the chosen machines should not be used. We chose to resolve such friction between strong semantics and transparency following the principle: Provide the parallelism transpar- ent form of a PSM command as its default, and oer more powerful forms of the command as options, or allow advanced users to dene more powerful commands from basic ones.

Resulting from AKAROA's three module structure, see Fig. 5.2, the ap- plication interface of AKAROA can be logically divided into a programming interface (i.e. the elements a user can use in his/her program to access ser- vices of AKAROA's Build and Control modules), and its runtime interface consisting of a set of commands for running parallel simulations (calls to AKAROA's PSM).

5.2.3 Model Construction

Beneting from the adopted object-oriented programming, AKAROA has been also equipped with an object-oriented toolkit, called Build, which al- lows users to work at a high level of abstraction when constructing new sim- ulation models, either by using already existing building component types (classes) or dening new components in terms of existing ones. A compo- nent may model any entity of a given simulatedsystem, for examplea priority queue, encapsulating its attributes, and procedures for their manipulation. One immediate benet of modular construction is that any component of the model can be readily and independently tested. Its data can be then ma- nipulated through specic access functions, such as functions for enqueuing and dequeueing, helping to protect its consistency. Lastly, components can be easily reused, either directly in another simulation or in denitions of new component types. Of course, simulation models already constructed can be directly incorporated in AKAROA; thus, the use of Build is optional.