High level design

From VisItusers.org

Jump to: navigation, search

VisIt is composed of multiple, separate processes, which are sometimes referred to as components. They are:

Name Overview Dependencies Design description
viewer Two primary purposes. First, it centralizes all of VisIt's state. When the state changes, it notifies the other components of the state changes. Second, the viewer is responsible for managing visualization windows, which often includes doing rendering in those windows.
  • VTK (for data models and plotting),
  • Qt (for popup menus),
  • OpenGL (for plotting)
here (under development)
gui Provides a graphical user interface to control VisIt.
  • Qt
here (under development)
cli Provides a command line user interface to control VisIt.
  • Python
here
vcl Launches jobs on remote machines. The VCL sits idle on remote machines, communicating with the viewer and waiting for requests for jobs to launch. When these jobs come up, it launches them. The purpose of this module is to spare the user from having to issue passwords multiple times.

None

here (under development)
mdserver The mdserver browses remote file systems, meaning it produces listings of the contents of directories. It also opens files (in a lightweight way) to get meta-data about a file, allowing the user to set up plots and operators without an engine.
  • Many I/O libraries (Silo, HDF5, HDF4, Exodus, NetCDF, more)
  • VTK
here (under development)
engine The engine performs data processing in response to requests from the viewer. There are both parallel and serial forms of the engine (called engine_ser and engine_par respectively). Rendering is sometimes performed by the engine, although it is also performed on the viewer.


  • Many I/O libraries (Silo, HDF5, HDF4, Exodus, NetCDF, more)
  • VTK
  • Mesa (actually mangled Mesa) and/or OpenGL
here

[edit] Connectivity & Communication

The connections between the various components are shown in the diagram below. At the lowest level, the the communication is done with sockets. However, two separate layers are built on top of that.

  • The first is for exporting state. The viewer keeps all of its state in various instances of VisIt's AttributeSubject class. UI modules (such as the GUI and CLI) subscribe to this state. (See the publish/subscribe design pattern by Gamma et al.) Thus, when state changes on the viewer, the AttributeSubjects automatically push this state out to its subscribers
  • The second is for remote procedure calls (RPCs). When a component wants another component to perform an action, it issues an RPC.
    • The RPCs come via a proxy class. For example, there is a module named "ViewerProxy". Both the GUI and CLI link in "ViewerProxy" and make method calls to this class. Each method call becomes an RPC.
    • Examples of RPCs are:
      • GUI or CLI initiating state change in the viewer
      • viewer causing the mdserver to perform an action, such as opening a file
      • viewer causing the engine to perform an action, such as drawing a plot

Personal tools