Design and Features

Basic considerations that lead to the design of VISIT were

CPU-time on supercomputers is expensive, so the simulation should be disturbed as little as possible by a visualization. All operations should be initiated by the simulation and are guaranteed to complete (or fail) after a user-specified timeout. This leads to a client-server model, where the simulation is the client and the visualization serves the clients requests (accepting connections, receiving results, sending back steering parameters).
Transparent bi-directional exchange of arrays of common data types (ints, floats, and strings) should be possible. With transparent we mean, that data-conversions between platforms should be performed automatically. However, expensive conversions to external formats like XDR should be avoided where possible.
Both the implementation and the API of VISIT should be light-weight to ease installation, use, and ports to new platforms.
The API should be independent of the underlying transport layer. TCP/IP should be supported. The implementation should allow for later integration of other transport layers (e.g. MPI-2, low level protocols like Myrinet-GM).
The contact between simulation and visualization should be established on the basis of 'service-names' rather than hostnames and port numbers. This eases the use of VISIT but requires some kind of name-service.
Language bindings for C and Fortran are a must, mixed-language programming should be possible.
VISIT should be able to co-operate with AVS/Express and other visualization tools that are in common use at the Research Centre Juelich.

Based on this, the current version of VISIT has the following features:

supported transport layers:
- TCP/IP
- File-IO pseudo transport layer for record/replay of simulation results
language bindings for
- C, Fortran ,Perl on the simulation (client) side
- AVS/Express, C, Perl on the visualization (server) side
currently supported platforms: Solaris, AIX, Linux, IRIX, UNICOS/mk. We have tested VISIT on these operations systems but it should be easy to port it to other UNIX systems with IEEE arithmetics.
includes SEAP (service announcement protocol), a simple directory service for exchanging contact information between simulation and visualization.
Optionally, the results can be multiplexed to several visualizations. Only one of them is allowed to send back (steering) data to the simulation. The facility is implemented as VISIT application that is able to connect to a single client (the simulation) but multiple servers (visualizations).