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).