Chapter 21
The EnSight Visualization Application
Randall Frank
Computational Engineering International, Inc.
Michael F. Krogh
Computational Engineering International, Inc.
21.1 Introduction ...................................................... 429
21.2 EnSight Architectural Overview ................................. 429
21.3 Cluster Abstraction: CEIShell ................................... 432
21.3.1 Virtual Clustering Via CEIShell Roles .................. 433
21.3.2 Application Invocation .................................. 434
21.3.3 CEIShell Extensibility ................................... 434
21.4 Advanced Rendering ............................................. 434
21.4.1 Customized Fragment Rendering ........................ 435
21.4.2 Image Composition System ............................. 437
21.5 Conclusion ........................................................ 440
References .......................................................... 442
21.1 Introduction
The vision behind EnSight has always been a full-featured, interactive,
high performance visualization tool capable of scaling to the largest data sets.
At the center of that vision is the ability to effectively leverage advanced
computer systems both at the desktop/display and in computational clusters.
This chapter reviews the EnSight framework for distributed application launch
and rendering. The distributed launch system facilitates custom deployment
of scalable EnSight visualization solutions. It has evolved to meet the increas-
ingly varied requirements of its users, including heterogeneous environments
with potentially complex and restrictive access controls. The rendering system
is specifically geared toward improved user interaction and advanced rendering
in distributed, high performance scenarios by exploiting advances in desktop
graphics card technologies and direct interaction methodologies.
429
430 High Performance Visualization
21.2 EnSight Architectural Overview
To place these commentaries in context, it is useful to provide a brief
overview of the EnSight visualization framework. EnSight [6] was designed
around a core, client–server architecture. The server provides the means for
reading data from storage through a built-in or user-defined reader. It is re-
sponsible for the extraction of geometric primitives from the data, which are
transmitted to the client for display. The client performs all of the graphi-
cal rendering and manipulation tasks using these primitives. Geometry and
commands move between client and server applications over an abstract com-
munications channel capable of leveraging TCP/IP, MPI, or other transport
layers via user-written plug-ins.
The core server includes the ability to read multiple data files as a single
data set utilizing a single process—thread-based, parallel processing. Larger
data sets stress scalability limits of the thread-based parallelism utilized in
the basic client–server application scenario. For such data sets, the framework
supports distributed memory processing (e.g., on cluster systems). The server
of servers (SOS) and collaboration hub (C-HUB) applications are introduced
in these scenarios. The applications provide the logic and processing necessary
to allow multiple client (C-HUB) and server (SOS) instances to work collec-
tively. The SOS can be used without the C-HUB to allow multiple servers to
interact with a single client, but the use of the C-HUB, to utilize multiple
clients, necessitates the use of an SOS.
In most visualization scenarios, the extracted geometric primitive data is a
small fraction of the size of the raw data. The magnitude of this data reduction,
coupled with client performance benefits realized though the exploitation of
modern programmable graphics cards, makes it practical to use far fewer
client instances than server instances for distributed visualization. For a large
number of cases, only a single client instance is required, resulting in the
common configurations shown in Figure 21.1.
The SOS provides distributed processing capabilities layered on top of the
core server, providing cross-server aggregation and dynamic object remapping.
The SOS also allows for optional automatic decomposition of a single data
set over multiple servers with dynamic ghost element generation. These two
features allow for N to M conversions between the degree of natural decom-
position present in the data set (N) and the number of servers (M). The SOS
provides a parallel asynchronous data reduction network (similar to the MPI
all-reduce functionality). This network allows servers and user-defined readers
to perform global computations, exchange particle trace locations, etc. The
SOS manages the merging and chunking of geometry packets from the various
servers, including the ability to compute new geometric decompositions that
target specific numbers of client applications. The revised geometric decompo-
sition is routed to the various clients via the C-HUB to load balance rendering
work over the clients.
The C-HUB serves to link together multiple instances of the client applica-
The EnSight Visualization Application 431
FIGURE 21.1: The basic EnSight application configurations. Top to bottom:
traditional client–server (Ensight Standard), single client multiple servers (En-
sight Gold), multiple clients and servers (Ensight Distributed Rendering—
DR).
tion and synchronize their interactions. It provides channels for the transmis-
sion of user interaction and scripted commands. More importantly, it gener-
ates routing information that the SOS uses to decompose geometry packets to
match the client configuration. The C-HUB routes the geometry packets gen-
erated by the SOS to individual clients with selective duplication of geometry
to specific client instances. When combined with dynamic head tracking and
support for multiple independent viewing frusta, the system enables flexible
tiled and CAVE configurations as shown in Figure 21.2.
FIGURE 21.2: EnSight parallel rendering for CAVE and planar tiled displays.
The geometry is duplicated on all of the clients.
The client provides an independent pixel fragment compositing engine net-
work, which allows the output of multiple graphics cards to be combined into a
single image. The source to this system was released by CEI as open source [2]
and a variation is currently available as the paracomp [1] library. Combining
dynamic geometry routing with one or more instances of the compositing sys-
tem allows clients to render to tiled displays, where each panel of the display
is driven by a separate compositing network as shown in Figure 21.3.
In a multiclient rendering configuration, the client process accepting user
input is referred to as the master and the other clients are referred to as
432 High Performance Visualization
FIGURE 21.3: EnSight rendering with parallel compositing. Chunks of geom-
etry can be selectively duplicated to parallel composite to a single display or
support multiple parallel compositing instances for tiled display output.
slaves. The master client’s participation in the parallel compositing system is
optional. The network topology of the session’s cluster and desktop hardware
tends to drive the decision. When the master and slave clients are located
on a common network (e.g., all on the same cluster), the final image delivery
is handled by the compositing library. In other situations, a remote image
transmission service is provided by the C-HUB. The C-HUB image delivery
service supports bandwidth-limited, asynchronous remote image transmission
with frame differencing and compression. When compared to generic remote
image delivery alternatives (e.g., VNC), it has the twin advantages of being
driven at image generation rates and being explicitly constrained to the ren-
dered image size. Moreover, user interaction is isolated in the locally executed
client, avoiding the latency overhead of remote event routing for many forms
of direct user interaction.
21.3 Cluster Abstraction: CEIShell
The obvious challenge presented by these varied configurations is how to
realize a specific instance of the framework (an EnSight session) within a given
site’s computational and networking constraints. At a minimum, an EnSight
session is composed of a single client and server. Optionally, a session might
also include additional servers and rendering clients, an SOS, and a C-HUB.
Traditionally, EnSight has used a configuration file scheme based on a se-
cure shell (ssh), or equivalent, for launching the various application instances
in an EnSight session. This approach works well in static and relatively ho-
mogeneous computing environments. However, increasingly complex security
requirements and system heterogeneity, coupled with an increase in scale and
The EnSight Visualization Application 433
system complexity, have predicated a move to a new launch system for the
EnSight framework. User requirements for the new system include support
for queuing systems, improved launch scalability, dynamic application config-
uration, VPN communications, session persistence, and enhanced debugging
capabilities.
To meet these requirements, CEIShell was developed. Simplicity and exten-
sibility were key themes in the design of the system. The simplicity of CEIShell
contributes greatly to its overall robustness and reduces the amount of work
necessary to customize it to specific platforms, queuing systems, firewall poli-
cies, etc. The system can be extended to support site-specific network and job
configuration protocols. CEIShell is a small C++ application that weaves four
concepts together: tree-based communications with other CEIShells, commu-
nications with locally running applications, a tag-based resource specification,
and local job management. Perhaps the largest benefit of CEIShell is the im-
provement in session robustness, stemming from the fact that EnSight can
probe potential session resources (e.g., validating environmental parameters,
OpenGL configurations, etc.) before attempting to launch the session.
A collection of CEIShells is invoked as a rooted, acyclic, tree network. Typ-
ically, command line parameters indicate parent–child relationships as well as
specific communication protocols and their parameters. The actual commands
used to launch the multiple CEIShells on the various computers are provided
by site-specific customizations. Issues such as remote computer access, net-
work security, cluster queuing system commands, and user credentials dictate
how applications, including CEIShell, are actually invoked on behalf of the
user. The commands to launch a specific instance of a CEIShell network are
commonly wrapped in a custom script that is parameterized by the site. For
example, the number of compute nodes, the number of rendering nodes, and
the users credentials might be parameters mandated by the site maintainer.
The EnSight client provides a customizable GUI that can be used to invoke a
site’s CEIShell network scripts along with any required parameterization.
21.3.1 Virtual Clustering Via CEIShell Roles
Along with the specification of CEIShell’s parent–child communication
parameters, a site customization script indicates what roles each CEIShell
provides. Roles are simply ASCII tags applied to each CEIShell instance. Each
shell may have any number of roles. The CEIShell itself does not dictate the
use of roles other than to use them to perform a resource search. A simple but
useful example of roles would be to give nodes in a cluster standardized names.
For example, one might allocate 10 nodes via a batch system on a cluster
but assign the roles “node00” through “node09” to the nodes. When EnSight
encounters a reference to “node04” in a resource or other configuration file, the
CEIShell network can remap the name via the roles to a specific, dynamically
allocated node. In this use-case, the CEIShell becomes a virtual cluster that
always appears the same to a calling application, regardless of which nodes
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.