For many years, EnSight has been able to operate in what we call "Server of Server" or "SoS" mode. In this situation, EnSight would operate on a patritioned domain (subset spatially), with each "EnSight Server" operating on its own spatial domain and its variables. There would be a collection of these servers, controlled by one "master" server called "Server of Servers". This method is conceptually similar to how solvers decompose the domain spatially into smaller pieces, and each node in a cluster could work on its own spatial region of the domain. In EnSight, this method works well when the spatial "weight" of the domain was too large for a single EnSight Server to efficiently operate (ie there were too many elements/nodes for a single server's memory... so the domain is split into N pieces, and M number of servers could be utilized to each load a small spatial portion of the model).
This works great for models which have lots of nodes or elements. What about models which have lots of timesteps, but perhaps not a huge amount of nodes or elements? What about the situation where you have ~40M elements (not really large enough for Spatial SoS), but have 1,000 timesteps, or 10,000 timesteps? Well, that is where the new capability "Temporal SoS" come in.
Rather than decomposing the domain spatially, this method decomposes the domain temporally. Instead of each server getting a subset of the spatial domain, each server is given the whole spatial domain, but a subset of the temporal domain. In this operation, you can spread the heavy temporal load over many computers, allowing you with the potential to traverse through time quicker.
What do you need?
a. You will need EnSight HPC license (or EnSight Gold license if using our old terminology).
b. We suggest always using the latest version of 10.1. Fixes and improvements are continuing, so ensuring that you are using the latest release is required. (currently 10.1.6(d)).
c. Transient dataset. Preferably one with lots of timesteps (many hundred/thousands).
How does it work?
You will be using a single EnSight Client, an SoS "master" node, and multiple (N) servers. Each server will read in all of the data associated with a particular timestep. As you march forward/backward through time, servers are already 'queued' with the next/previous timesteps' information, and can be passed straight to the client to operate with. Servers then play leap frog with the timestep loading, ideally maintaining a buffer of available timesteps forward or backwards.
From a user perspective, the only thing he/she has to do, is to activate the Temporal SoS in the File -- > Open Dialog when you initially load the model. All remaining items are taken care of behind the scene.
The user must specify how many "EnSight Servers" to utilize. This can be done either when launching EnSight through CEIStart, or via resource file (.res). How many? See discussion below.
Note: In order to see the "SOS Options" in the File Open Dialog, you must be running EnSight HPC with the SoS option when launching EnSight.
What performance to expect?
This depends upon many factors, including your internal network, your particular model, and your the operations which you perform.
In this situation, there are three basic phases which take time:
a. the time it take for the server to change timesteps, read the data, load the parts and variables, and compute all of the dependent parts and variables.
b. the time it takes to communicate the results to the client.
c. the time it takes the client to update all of the parts it has loaded, and update all associated user interface items.
The total time it takes to march through time is Nsteps * (a + b + c). Scalability in Temporal SoS is based on the relative fractions of (a) and (b+c). If they are balanced, you will experience optimal speed, and you will not experience any further improvement in speed with additional EnSight Servers. Essentially, the time of (b+c) creates a "shadow" in which you can attempt to stack some number of (a) servers. You should be able to achieve reduced performance until the shadow is full (your limit of b+c).
How many servers should you use?
It is not easy to determine this. At the limit you will want to use at most N = number of timesteps in the dataset. But in reality you will not need this many. You will need — assuming everything scales linearly: (a)/(b+c) + 1 number of servers. At which point there is no benefit in adding additional servers. In other words, if a server can update to a new timestep in the “shadow” of the communication and client time you are at maximum performance.
Rule of thumb: Start with 2, 4, 6, 8 servers. Check scalability, and reduction in time as more servers are added.
What shows benefit, what shows little/no benefit?
1. Server-side heavy calculations typically perform fairly well. Items like Grad() calculations which require significant server time benefit from having temporal SoS operations.
2. Clip planes, colored by a variable, and played over time tend to benefit fairly well.
1. Pathline creation does not show much benefit when run in Temporal SoS due to the chronological order in which the pathlines must be integrated.
2. Client-side heavy operations like rendering many isosurfaces tends to be the limiting factor. Volume Rendering also is very client-side heavy operations, and will limit any scaling in performance.
3. Queries over time do not scale. These are performed on a single server.
4. Calculator functions that computes over time will not scale (TempMean(), TempMinMax(), etc).
Frequently Asked Questions:
1. For interactive or batch use? -- > Ans: Both.
2. Does the network matter? -- > Ans: Yes. Very much so. This effects time "b" in the scalability relationship. This can quickly become a bottleneck.
3. Where should the servers be run? -- > Ans: Typically, you will want to spread out the EnSight Servers on their own machine if possible (as opposed to piggy-backing multiple servers on a single machine).