How to improve performance (speed, memory usage, parallelism, etc.).
Updated for EnSight 10.
This FAQ is a collection of tips that can make working with large data
easier and/or faster. The definition of big data can vary greatly.
However, EnSight has been successfully used with problems as large as
11.5 billion unstructured hexahedra and is routinely used by customers
for transient problems containing a half billion elements per time
step. You don't need to have that much data to take advantage of
these tips, although. Some can be quite beneficial for "small"
problems of only a million elements.
If this FAQ is of interest to you, you might want to check it
periodically as we add additional tips. And, if you happen to have
one that isn't listed here, let us know.
If you have questions about a particular tip, don't hesitate to
contact CEI support.
Context, Command, Archive, and Data Files
Context files, command files, and archive files can all be used for
saving the state of EnSight for later restoration.
A command files is automatically created as you operate EnSight. It
records each and every command executed by EnSight (including all
those color palette modifications, for example). They are useful for
recording and replaying an exact sequence of commands. If you are
replaying command files, consider modifying them to add the commands
'command: delay_refresh on' and 'command: delay_refresh off'.
Delaying refreshes prevents redrawing the graphics after most
commands. You can edit the command file and insert 'command:
delay_refresh on' near the beginning and 'command: delay_refresh off'
near the end.
To restart EnSight faster consider using context files instead of
replaying command files. When you start EnSight with a command file,
it will playback each and every command that was saved at the time the
command file was created. This typically includes everything you did
(including all those palette modifications, iteratively guessing the
'right' isosurface level, etc.). A context file is similar to a
command file except that it contains only the commands needed to
reproduce what is needed at the time the context file was created.
Thus all the extraneous commands are culled. Additionally, context
files can be used for easy A/B case comparisions. See the EnSight
User's Manual for further information on context files.
Archive files can be thought of as 'checkpoint/restart' files. They
are useful for saving the complete state of EnSight in a set of binary
files that can be quickly restored. While they tend to be portable
between minor version updates, incompatibility problems are possible
between major version updates. However, if EnSight has difficulties
in restoring the archive, it will create a command file that can be
If you're using EnSight 5 or EnSight 6 formatted data, switch to
EnSight Gold formatted data. EnSight can typically read in these files
up to 10 times faster that the previous versions. It is also much
faster than many of the 3rd party solver formats.
If you are using EnSight formatted data, be sure it is in binary
format and not ASCII format.
If you are using file formats other than EnSight's, consider
translating them to EnSight format using EnSight. In some cases
(e.g. MSC.Dytran and LS-Dyna), file access can improve by a factor of
10X by converting the files. How to do this? Select all parts of interest,
If you're using a User Defined Reader (UDR) to load data, make sure the
reader uses the 2.x version of the UDR API. It has various
performance optimizations and similar performance gains as the EnSight
Gold format reader.
Memory reallocation can be very expensive. EnSight will try to make a
guess at the maximum memory it might need for a transient problem to
avoid reallocation. However, this isn't always accurate and can vary
greatly depending upon user actions. You can help EnSight guess
better by loading the last time step first since that is typically
among the larger time steps in a transient problem. Note that this is
the default action but can be changed in the User Preferences or in
the Data Reader dialog. If the largest step is not the last, then
load it first.
Be sure your computer has enough memory and is not swapping due to
insufficient memory. Swapping memory to disk can be over 10 times
slower. Memory is relatively cheap and can be one the best
You can monitor memory usage under Unix and Linux with commands such
as 'top', 'ps', 'vmstat', or some other vendor supplied command.
Under MS Windows, use the Performance tab available through the Task
If you are running both client and server on the same computer and are
running low on memory, consider running the server on a remote
computer which has more memory.
The server needs enough memory to load selected parts and activated
variables. Typically, it caches only 1-2 time steps from a transient
problem. It never loads the entire transient problem into memory at
one time. As a rough rule-of-thumb, the server uses 100MB-200MB
actual usage can vary greatly depending the particular features used
geometry (e.g. displayed polygons). This is typically on the order of
10's of bytes per polygon. However, the computer's graphics driver
may require an equal amount of memory depending upon it's
What are the various ways of
animating transient data and their tradeoffs?
The first way is to simply stream the data in from disk by clicking
on the clock icon and clicking the play button. This has the advantage
of storing at most only two timesteps in memory, and can provide satisfactory
animation if the model size is small relative to the disk data rate and
the rendering speed.
The second way is to click on the flipbook icon and
choose the Load As Images pulldown selection, then click load.
This will cache the images in memory and
can provide satisfactory animation for large models on slower
machines with memory adequate to cache the animation images.
For large models, caching only the screen image at each timestep
can provide substantial memory savings over storing the model as objects.
The downside is that the geometry cannot
be rotated or translated during the animation.
the flipbook as Objects (choose the Load As Objects pulldown selection)
This has the advantage of caching the visible geometry as objects,
allowing model manipulation during the animation.
The downside is that storing the geometry as objects can quickly use up memory if the
geometries are large or there are a large number of timesteps.
Monitor your memory when using the flipbook.
That provides a coarse overview of the data to assess how much time and memory this is going to take.
Then play that flipbook and get an assessment of the entire transient run at a coarse spacing.
Then load every 10th one, being careful to toggle OFF the Regenerate All toggle so that
EnSight doesn't reload the every other 20th flipbook times that have already been loaded.
Then narrow in on every fifth, and finally every other one, then finally every one, always
Graphics Performance on the Client
To save memory on the client computer, be sure to use the 'non-visual'
part representations for parts that don't need to be visible
(e.g. fluid parts). 'Non-visual' representation is different than
simply turning off the visibility of a part. Non-visual will not load
any of that part's data in the client whereas turning off visibility
will simply not draw the data. Note that non-visual parts are still
fully available in the server for other operations.
by the speed of the graphics accelerator in the computer where the
client is running. New accelerators can be a magnitude faster than
those just a year or two old. Check CEI's web site for rendering
performance figures benchmarked on numerous systems and compare those
to what you get while running the CEI benchmark (found by clicking on the
can be purchased for several hundred dollars (at least for a PC
platform) making this an inexpensive upgrade.
Be sure you are running the client on the system you are sitting in
front of. If you run the client on a remote computer, the OpenGL
graphics commands will be sent across the network from the computer
running the client to the computer you are displaying on (unless you
have specified software rendering with the -X option). This can be
If your desktop computer is quite old or doesn't have a capable 3D
graphics accelerator and you are having weird graphics problems,
Please check your graphics card and make sure you have the latest
graphics drivers installed. Check with either the computer vendor or
the graphics card vendor. The original drivers are almost always
slower (and buggier) than those available for download.
If your computer is too slow for the amount of data it needs to render
(ie. rotating the model takes a long time), toggle on Fast Display.
Note that each part can have a different Fast Display Representation.
Also consider using the other display representations
(e.g. non-visual, bounding box, feature angle) for some parts. Or, use
a surrogate object such as a cut, extract, subset, XYZ box clip, in
place of the normal part.
Transparent objects take at least twice as long to render. Consider
using transparent fill patterns instead of using true transparency if
possible. When done using transparency, be sure to set the
Transparency/Opaque value back to 1.0 to turn it off. Note that if
smooth shading is on and you have more than one transparent part, then
rendering performance will be significantly slower.
If you have vast of amounts of geometry to render and applicable
hardware, consider using multiple renderers in parallel. See Chapter
2 of the EnSight User's Manual for details.
Load your data as all non visual. How to do that? File >open
Select your case file.
Click on Select parts to load...
part names will be displayed as grayed out (not loaded).
Select all parts and right click load parts.
Make the visual rep nonvisual
Now the parts are not loaded on your graphics window. They are only loaded on the server .
As non visual nothing is sent from the server to the client.
Now do a couple of things such as activate variables and change one timestep.
How long did that take?
That will give you an idea of how long it takes to simply load your geometry
(it has to load your geom each timestep) and your variables (all active vars are loaded each timestep).
This gives you an idea of I/O speed of the server without sending anything up to the client.
This will give you a lower bound on the best performance possible.
Now you can start to see how things change with a calculation.
You can select your fluid now and calculate an isosurface and see how long that takes.
You may need to do a Fit to get it to the screen as the screen was not zoomed in to anything as there was nothing visible.
Now change through time and see how fast that is.
You can change that to an isovolume and change through time and see how fast that is.
The client, server, and SOS server all contain thread-based parallel
operations for shared memory, multiprocessor (SMP) computers. You can
control the number of threads used by each of these EnSight 10 applicatioins
via the ENSIGHT10_MAX_CTHREADS, ENSIGHT10_MAX_THREADS, and
ENSIGHT10_MAX_SOSTHREADS environment variables.
The client has a practical limit of several
dozen threads whereas the server has a practical limit of
approximately 8 threads. Actual scalability is highly dependent on
the amount of data being operated on, type of SMP, and actual EnSight
operation used. EnSight threaded performance yields benefits
for problems consisting of several million elements or greater per
To date, the client uses multiple threads for transparency resort,
display list generation, and multi-pipe rendering. Note that the
-no_display_list option must be used for threaded display generation
which prevents the use of the graphics accelerator's internal display
The server uses threaded parallelism for clips, isosurfaces, min/max
operations, stream lines (but not pathlines nor surface restricted
traces), transient read-ahead (SGI only), and various internal
algorithms. Note that once a clip or isosurface is calculated for a
particular part and variable, its internal data is cached and not
recalcuated in parallel.
The SOS uses threaded parallelism for server invocation.
For much better parallel scalability, consider using the EnSight
Server-of-Servers (SOS). SOS works equally well on SMPs as well as
distributed memory systems (e.g. clusters). In some cases, SOS
performance on an SMP can yield even greater scalability than threaded
performance on the same SMP using the same number of processors. When
using SOS be sure each server has a half a million elements or greater
(roughly) to prevent being network limited. SOS performance will be
limited by the server with the most data; thus load balancing of the
data amoung the servers is essential. Note that most future
parallelism in EnSight is targeted at SOS parallelism instead of
SOS and server threads may be used together.
If you are running on a shared system, be sure other jobs aren't
interfering with your resources (cpu, memory, disk, network, graphics,
Don't load parts and/or activate variables unless you need them. If
Consider using batch processing (-X and -batch command line options
along with a command file).
Work with a smaller portion of the data while interactively determining
appropriate values (e.g. isosurface level, color palette values). You
can get a smaller portion of the data via the subset tool or via a
clip, for example.
While adjusting the color palette with its detail editor, turn off
'Immediate Modification' from the Edit menu. This allows you to
manipulate the palette without redrawing the affected geometry. To
update the geometry's color, click the 'Apply Changes' button in the
For rendering acceleration, try polygon reduction.