• Introduction
  • How COVISE works
  • History
  • First Steps
    • Start Parameter
    • Configuration File
      • HostConfig
      • UIConfig
      • Additional information for using a MultiPC system:
      • License

Introduction

COVISE stands for COlaborative VIsualization and Simulation Environment. It is an extendable distributed software environment to integrate simulations, postprocessing and visualization functionalities in a seamless manner. From the beginning COVISE was designed for collaborative working, allowing engineers and scientists to spread on a network infrastructure. Processing steps can be arbitrarily distributed across different machine platforms to make optimal use of their varying characteristics. High speed network architectures of different kinds can be properly incorporated into COVISE. Industrial or research simulation codes are easily integrated into this distributed software environment by wrapping the code as a COVISE module. If required, the open design allows easy extension of the COVISE architecture.

None of the currently available visualization packages supports all of the following features availabe in COVISE.

• Distributed Working

• Supercomputer Usage (parallel or vectorized)

• Collaborative Working

• Integration of Custom Codes

• Virtual Reality

• Time Dependent Simulation

Figure: Visualization of Data with COVISE

COVISE is a modular and object-oriented software system. To visualize data several processing steps, called modules, are used. Each module is executed as a seperate operating system process and communicates with the central Controller and the local data request broker CRB by sending or receiving control messages via TCP/IP sockets. Modules are connected into a strictly unidirectional data flow network also called module map. Loops are not allowed, nevertheless, there are possibilities to send feedback messages from later to earlier modules in the processing chain. A Qt based user interface the Map Editor gives the user a tool to perform all the necessary interactions.

Data exchange is handled different from control flow. Within a machine pointers to shared memory are used to avoid copying of data objects. Between machines data objects are transferred by the COVISE request broker CRB, including necessary format conversions.

How COVISE works

Most visualization systems currently available focus on the visual programming paradigm in an algorithm-oriented way. Data itself cannot be accessed by the user directly, but exists only internally. Means are provided to connect modules to networks which perform certain visualization tasks, but the access to the underlying data mostly is limited to typing a filename in the input module.

There is no explicit control of data by users within most of the current dataflow based visualization systems. Thus either data produced by intermediate steps is kept even if it is not needed any more, or this caching mechanism can be switched off globally. As data does not exist as directly accessible data objects, selective handling is not possible. On the other hand a user who wants to examine a certain time interval repeatedly would be delayed by the application creating the same temporary objects over and over again instead of creating the sequence once and then displaying it just from cache.

Based on experience with own developments other packages available commercially or as open source, a system architecture has been designed which fits the needs of a high performance distributed visualization application.

Figure: Local Working in COVISE

A modular approach allows for the most flexibility in distributing certain parts of the visualization application to specific computers. The need for excellent high speed network utilization makes it necessary to put emphasis on the management of the network connections depending on the nature of transferred data. The database approach makes a data request broker CRB necessary. This combination defines the COVISE architecture.

The Controller is the central part of this architecture. It has the overall view of the whole application. This Controller supervises the distribution of modules across the involved computers as well as the management of the execution of the application.

So an application module only needs connections to the Controller and the request broker CRB. The Controller supplies the application module with the information that is necessary to guarantee the proper execution of the overall application. The data that will be exchanged between subsequent application modules is stored under the control of the request broker CRB. This allows a very simple structuring of an application module.

The implementation of the COVISE system architecture is done in C++. The basic communication functionality is provided as a library.

For Distributed and Collaborative Working see Chapter 5, COVISE CE.

History

The development of COVISE was initiated in 1993 in the CEC RACE project R2031 named PAGEIN (Pilot Applications in a Gigabit European Integrated Network). The aim of PAGEIN was to evaluate possibilities of distributed computing and collaborative engineering on top of European high speed network infrastructures. One of the activities was the design and development of a software architecture as a testbed for the evaluation. The design of this basic architecture was led by the Visualization Department of the University of Stuttgart Computing Center (RUS). It was later called COVISE. Also the main components of COVISE as well as many application modules have been developed at RUS. With the project partners group from the aerospace field the application scenario was the simulation and analysis of air flow in the design phase of new airplanes. While initially industrial partners only defined their requirements they became more involved when they recognized the potential of CSCW (computer supported cooperative working) and COVISE for the engineering field.

As a result COVISE was used in the Esprit project ADONNIS (E9033) between Daimler-Benz Aerospace Airbus (DBAA, Bremen, Germany) and RUS (Stuttgart, Germany) via a 2 MBit/s leased line (permanent for one year). This allowed engineers of DBAA to evaluate cooperative working in an engineering simulation and design department.

In the project EFENDA sponsored by the German ministery of education and research BMBF the integration of modules from the airplane design field into COVISE as homogeneous software integration platform was performed to increase the productivity of the airplane developer.

In the final phase of the ADONNIS project a short demonstration of CSCW applied to the analysis of vibration simulations of satelites was given. This prove of concept led to the definition of an Esprit best practice and demonstration project ACATAD with CASA (CONSTRUCCIONES AERONAUTICAS SA Division Espacioas) as the primary industrial partner in which collaborative analysis of dynamic simulations among satellite producer and sub contractors is introduced. COVISE will be used across multiplexed ISDN lines.

Also the COVISE development was initated in the aerospace field the underlying concepts and architecture are independent of a certain application field. Thus it was possible to also apply COVISE to the automotive applications.

In the Esprit project (E20184) HPS-ICE, (High Performance Simulation of Internal Combustion Engines), INDEX (E22745), COVAS (E22542), the BMBF-project EFENDA, the G7-Projects SPOCK and GWAAT, the Collaborative Research Center (SFB374) and many other national projects.

Since 2004, the development of COVISE is a joint effort by HLRS at the University of Stuttgart and RRZK at the University of Cologne.

In 1997 the developers of COVISE founded the company Vircinity IT-Consulting to bring COVISE to the market. COVISE is now distributed by VISENSO GmbH.

First Steps

On Windows, a new COVISE session can be initiated from the Start menu or by Desktop icons. On UNIX systems, the installation process appends the path to the COVISE executables and modules to the environment variable $PATH. Thus, starting COVISE should be as easy as typing covise in a shell window. If the command covise is not found, please contact your system administrator.

Initiating a COVISE session will start the following processes:

1. Controller (covise)
2. CRB (crb)
3. Map Editor (mapeditor)

After the starting phase the Map Editor window will appear .

Start Parameter

COVISE can also be started with parameters. Typing covise --help will show you the syntax.

The following start options may be useful for you:

• -i start with Map Editor as icon
• -e execute immediately after loading
• -q quit after 1st run (only together with -e)

Configuration File

Scope-name { : hostname}
{
	Var-Name1	string2
	Var-Name2	string2
}

HostConfig

HostConfig
{
# Hostname   Shared Memory     execution mode      timeout [s] Min. SHM
#           (shm|mmap|none) (rexec|rsh|ssh|manual) (default 5)  segment
   mike          shm               ssh               360          32MB
   peter         shm               manual            360
   george        shm               rsh               360
}

For workstations and PCs the memory model is shm (shared memory). There are other memory models for supercomputers like CRAY.

When using shared memory, COVISE manages multiple shared memory segments and tries to put its data object in free spaces of these segments. If no memory is left, it will allocate an additional segment. The size of this segment is the minimum of the required ize for the object and the minimum allocation size specified in the config file.

Small minimal SHM segment sizes will reduce memory consumption, but increase the number of segments and add overhead. Both maximum size of shared memory usage and number of segments are limited by operationg system and machine configuration.

If no value is given, the following defaults are used:

Linux:              8 MB
SGI n32 and HP:    16 MB
SGI 64bit:         64 MB

UIConfig

UIConfig
{
ShortCuts  RWCovise Colors Collect CuttingSurface IsoSurface Renderer
ModulIcons colored
}

In addition, you can use UIConfig to specify a browser for displaying online help or other online documentation; default is

Browser        netscape

Additional information for using a MultiPC system:

In order to improve the performance of COVER under Linux, you can use 2 synchronized PCs running in parallel instead of 1 PC using a dual graphic card. One of them will be the master and will be connected to the tracking system. The PCs will be connected through TCP/IP and serial connection. The serial cable will be plugged into one of two serial ports which has to be specified in cover.config, section MultiPC, key "Serial_Port". Master and Slave (names of the machines) are defined in the same section. In addition, you have to define the type of connection between the hosts in covise.config, section HostConfig (like in collaborative working).

Example:

HostConfig
{
#  Hostname    Shared Memory    execution mode    timeout in seconds

      pc1        shm               rsh               -1

      pc2        shm               rsh               -1
}

MultiPC
{
    Master        pc1
    Slave         pc2
    Serial_Port  /dev/ttyS0
}

License

License
{
Key NFLHOODOLEBLILIEDEMLMNJGAJDPPHHHCDCIDPGDHABJKAKN    visage    31.12.2001 
}

Most of the currently existing scopes are mainly used by the controller, the user interface, the desktop renderer and the VR renderer. You can find more details about single scopes in the chapters explaining these central COVISE parts.

Next