Follow

Performance tips

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 
used instead. 

 
Data file format

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,
activate all variables of interest, File>Export>Geometric Entities, or
File>Save>Geometric Entities in older versions of EnSight and choose
EnSight Case Gold.  This will save to the EnSight's server's working 
directory if you are using client / server mode.


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 Utilization 

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 
performance boosters. 

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

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 
of RAM for every million normal elements and perhaps 10x that number
for nfaced polyhedrons. This is a very rough estimate given that 
actual usage can vary greatly depending the particular features used 
within EnSight. 
 
 The client only needs enough memory for the visible 
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 
implementation. 
 
 The SOS requires memory equal to the largest server's 
memory usage. 

Transient data animation

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 third way to animate your data is to load 
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. 

Loading a flipbook incrementally with large number of steps
 
When you load a flipbook with a large number of steps (say 100), set the Load 
increment to be large enough so that you only load 5 or 6 steps.

 

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 
leaving the Reload All toggle OFF, so you don't have to repeat the loads already completed 

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. 

If you have a lot of visible geometry, rendering performance is limited 
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 
User Tools icon along the top icon bar and in the resulting dialog in
Utilities> performance test python tool). A very fast graphics accelerator 
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 
quite slow. 
 
Make sure that the Title bar above the icons does not say Software
Rendering. Software Rendering means that EnSight is not using your
hardware graphics card and is much much slower.  

If your desktop computer is quite old or doesn't have a capable 3D 
graphics accelerator and you are having weird graphics problems, 
then software rendering (-X command line option as in
ensight100 -X) may eliminate problems. However, a good 3D graphics 
card can speed rendering performance and interactivity several orders 
of magnitude. 

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. 
 
How to tell if the Server is slowing you down
 
Query>Dataset
and see if your geometry is static (only loaded once), 
changing coordinates (only coords loaded when timestep is changed)
or changing connectivity (entire geom is reloaded each timestep).
This has an impact on speed. Only load the parts you need.
 
Characterizing Performance Empirically

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

Load

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.

 
Parallelism 

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 
time step. 

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

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 
threaded parallelism. 

SOS and server threads may be used together. 

Miscellaneous 

If you are running on a shared system, be sure other jobs aren't 
interfering with your resources (cpu, memory, disk, network, graphics, 
etc.). 

Don't load parts and/or activate variables unless you need them. If 
you've done several steps in your analysis and have a trail of 
active variables and now want to load a flipbook showing just one 
variable, deactivate all the unnecessary variables and delete the 
parts unnecessary for the flipbook so that EnSight doesn't need to
load large numbers of unnecessary variables and create unnecessary
parts each timestep.

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

For rendering acceleration, try polygon reduction.
Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments