To model a simulation, we designed a description language which allows the user to describe the input parameters and the output data of the simulation. It can be seen as a light-weight and dedicated CORBA-like interface description language. Several sections must be present in such a file: a description of the simulation program, a set of input parameters, and a set of output data. Graphical objects can also be described. An example is presented in Table 1. A graphical interface is available to describe such a file (Figure 3).

·  Figure 3 - Graphical Interface

To be able to start the simulation, the user must give information about the executable such as its name and directory. This is specified in the Simulation section. The way to feed the simulation with the input parameters should also be specified, for example as a command-line or with an input file. The system should know how to acquire the output data produced, for instance on the standard output or from a file.

·  Table 1 - A sample description file

Data manipulated by the simulation can be described using either the provided built-in types or by some types defined by the user. The basic types defined in the system are: long, floating-point, string, 2D-point, and 3D-point. New types can be described by combining basic types. An example can be seen in Table 1 (type PointTime). All these types can be used in scalar, list, and matrix objects.

Input parameters are described by a name, a type, a dimension (scalar, list, or matrix) and an optional input value when applicable (scalar object). Any number of input parameters can be specified by several Input sections. Output objects are given in a similar way using Output sections. Finally, it is possible to specify graphical objects. Such an object is the graphical representation of an output data produced by the simulation. The user is able to interactively modify these objects, steering visually the simulation. The value of such an object should be an output object, and the type can be selected among several ones (sphere, line, surface, etc).

2.   Code generation

  ·  Figure 4 - A resulting architecture

We wrote a code generator for the description files. It generates C++ code for the CAVERNSoft [Leigh99] network layer, as shown on the right part of Figure 1. We selected CAVERNSoft because it provides functionalities to build networked virtual environments and because it is widely used in the VR community. CAVERNSoft, based on the Nexus communication library from Globus, uses a ``publish and subscribe'' paradigm. A site can define keys to publish its own data, and a remote site that subscribes to these keys will automatically receive the data through callback functions. This mechanism can be used for small data (tracker data) to large data sets (data-mining) using different policies. CAVERNSoft supports persistence, thread management, and network protocols (TCP/UDP/multicast). It also provides some facilities for avatars and 3D models using the SGI Performer library.

Our code generator produces C++ classes for the server object and the proxy object. Each of these objects contains a threaded IRB (network object of CAVERNSoft) and defines a set of keys with their associated callback functions. For each input or output object, a key is defined to transmit the value. The marshaling code for all the types is generated to be able to use our system in a heterogeneous environment. A set of keys is also created for the control of the simulation (initialize, start, stop, pause, resume, shutdown methods). It is therefore possible to manipulate proxy and server entities as C++ objects, without dealing with network issues. Figure 4 presents the resulting architecture corresponding to the description file of Table 1. It shows the relation between the server object (as referred in Figure 1) and the proxy object. For the server, we generate an program which is basically a endless loop waiting for remote method invocations. The proxy object is embedded into our VR framework. Performance issues are discussed in the full paper.

3.   VR framework

·  Figure 5 - VR framework

Besides the code generator, we developed a virtual reality framework to steer and visualize the data produced by the simulation. It is built on top of the Performer library to exploit the high performance of SGI workstations and on top of the CAVELib library to control VR devices (multi-screens and tracker management), as shown on the left part of Figure 1. The architecture is described in Figure 5, focus-sing on the VR framework as referred in Figure 1. It consists of a shared-world where the objects of the simulation are represented. These objects are updated through the generated proxy object. An interaction module allows the user to send commands to the proxy or to directly manipulate the objects of the simulation to steer it. This framework is functional but still under development, following the needs of the applications described in the next section.

·  Figure 6 - CAVEStudy laboratory

Figure 6 shows the default virtual environment provided by CAVEStudy. It consists of a virtual laboratory with a manipulation box where data can be inserted, and a board to present some text information.