The way you compute computational fluid dynamics (CFD) problems on Rescale is very similar to running on your local environment. Some of these tips may be obvious to those familiar with CFD but here are a few suggestions, in no particular order, for running CFD on Rescale.

Garbage in, garbage out

It goes without saying that a good mesh could make or break your run. But before focusing on the mesh quality, one should always ensure that the job they wish to submit to Rescale should run end-to-end locally. Occasionally, there are users who use hundreds of cores expecting it to run for many days, only see it “finish” in a few seconds. We all make mistakes, but it is probably not productive to repeatedly make small mistakes that have a big cost. Executing a small case of what you will be running locally will save your time and your wallet.

Watch your step

The Rescale platform has a Live Tailing feature that allows you to view all the files while the computation is in progress. It is helpful to know if there are errors or the progress it has made. However, in CFD you are also interested in knowing the residuals and certain values as the simulation progresses.  One way to monitor your iteration is writing out the plot as image file(s).
The figure below is an example of a residual output from STAR-CCM+ running a steady-state problem.


This residual plot is written out as a jpeg file with the code shown below. You will probably need to make changes to this code to integrate with your code.


Alternatively, you could plot your own figure with the built-in-tools. For software that writes the residual log as ASCII file, one method to plot the residual is by using gnuplot.


Below is a code for gnuplot to write a jpeg image file of the residual plot. One should modify the example code below to suit their own CFD software output.


Guide your run

Sometimes it is necessary to intervene during the computation and change some settings, such as relaxation factor, save interval, or solver parameter. One can ssh into the compute cluster having set an ssh key in their account settings. For details, see here. Intervention may help save a run if one identifies bad parameter choice(s), thus avoiding submitting a new job. Of course to know if you need to intervene, you will need to be watching your step.
One could also run a non-graphical interactive session if the CFD software supports it. Below is a screenshot of the terminal session of ANSYS Fluent.


For hoarders – package files

Result files are precious, especially with all the work that went into just getting it to run. Some software writes out many files of relatively small size (less than few MB). With thousands of these files, the data transfer time after the computation completes can become a large portion of the job duration. This data transfer applies both to when the results are transferred to the storage space as well as when you download the results to your local workstation at a later time. The large number of files and large file size might not be avoidable in CFD, however, packing up many files and writing in binary can mitigate the time spent on going for a coffee break.

As an example, OpenFOAM writes all its field solutions in separate files (e.g U, p, T, … etc.). This is convenient for post-processing or using the output for another input, but creates many files. One could write in binary and limit the write interval in the system/controlDict setting. Additionally, packaging up the results with tar or zip is strongly advised, but then again… coffee might be calling.

Looking into the Rescale cloud

Result files too large for your bandwidth aren’t a problem anymore. You can view them without downloading the results. Simply start a remote desktop and load your job that is in progress or a completed job. Shown below is a Windows remote desktop session (Linux is also available).

Another option is to start ParaView on the job cluster and use ParaView server to view the results. Compared to the remote desktop, this is limited to the operations of ParaView. If all you wish to do is view and extract certain data, this may be all you need. For more details see here.



This article was written by Hiraku Nakamura.


We have now made it easy to not only see a summary of your current usage, but have also added the ability for you to export your detailed usage. Here’s how:

  1. While logged in to your Rescale account, click on your email address in the upper right corner, and then select Account from the menu that appears.Screen Shot 2015-04-27 at 6.25.15 PM
  2. On the account page you’ll see a summary for the last few months. There is a link on the right to download your usage for each month in a comma-separated values (CSV) file, which can be easily opened by Microsoft Excel for further analysis.


You can also view a summary of any credits you have received and a usage chart by clicking on the corresponding links in the menu on the left.

This article was written by Adam McKenzie.


by Clayton Grow, PE, Account Engineer
Convergent Science, Inc.

Mel Brooks and the Paradox of Motion
            “We can’t stop; it’s too dangerous; we’ve got to slow down first!
                        –Colonel Sandurz, in the Mel Brooks film, Spaceballs (1987)

This is one of my favorite lines from the Mel Brooks screwball/sci-fi spoof film. But for the longest time, I didn’t realize why. Then, in an Introduction to Philosophy course, we talked about Zeno’s “Dichotomy paradox”. Essentially, it says that in order to travel from point A to point B, you must first travel 1/2-way there. But in order to travel 1/2-way there, you must first travel 1/4 of the way there. But in order to travel 1/4 of the way, you must first travel 1/8… reductio ad absurdum.

It dawned on me that this goofy line was sort of like the Dichotomy paradox in reverse: in order to stop, you need to slow down to 1/2-speed. But before you do that, you need to slow down to 3/4-speed, 7/8-speed, 15/16-speed… Maybe Mel Brooks didn’t intend this line to draw attention to a philosophical conundrum, but it certainly opened my mind to the relationship between paradox, absurdity, and humor.

 Achilles, the Tortoise, and a Solution to the Paradox

So, is motion an illusion? This possibility was disconcerting to me, of course, so I researched others’ opinions on the matter. My favorite explanation came in an unlikely place: an essay by the author of the renowned children’s book Alice in Wonderland. In the first few lines of his essay “What the Tortoise Said to Achilles” (based on Zeno’s “Achilles and the tortoise” paradox, a close corollary of the Dichotomy paradox), Lewis Carroll introduces a practical solution:

Achilles had overtaken the Tortoise, and had seated himself comfortably on its back.
“So you’ve got to the end of our race-course?” said the Tortoise. “Even though it does consist of an infinite series of distances? I thought some wiseacre or other had proved that the thing couldn’t be done?
“It can be done,” said Achilles. “It has been done! Solvitur ambulando.”
Solvitur ambulando is a Latin phrase loosely translated as “it is solved by walking.” A common usage of this phrase is “the problem is solved by practical experiment.”

In other words, how can you travel from point A to point B when you know there are an infinite number of smaller distances you need to travel through first? Simple… just start walking.

The Paradox of Solution 

Solvitur ambulando is easier done than proved though. What if we don’t know in which direction point B lies? What if our first step is too far? What if point B is a moving target?

Things quickly get sticky. 

The Solution to the Paradox of Solution: Prediction 

The same concept applies to computational fluid dynamics. We want the simulation to move toward a solution, or more accurately, an elaborate system of solutions. We need to know the velocity, pressure, temperature, species concentration, etc., at various locations in the domain, at each time-step.

What is our first step toward achieving each of these solutions within this elaborate system? We certainly can’t just start walking in a random direction. But we also can’t just stand still. So we start with an estimate. 

Prediction of Conditions: The PISO Algorithm 

In order to systematically solve each condition at each time-step, Convergent Science’s innovative CONVERGETM CFD solver uses an algorithm called the PISO algorithm, which stands for Pretty Interesting Scientific Operation. (But seriously, if you’d like to know more about the PISO algorithm, pick up a copy of R.I. Issa’s riveting — and frequently cited — article, “Solution of the Implicitly Discretised Fluid Flow Equations by Operator-Splitting” in the Journal of Computational Physics, Volume 62, 1986.)

At the risk of over-simplifying things, you can think about the PISO algorithm like this: You begin a hike by looking at a map, then you pick which direction you should walk, based the location of landmarks. After a bit of walking, you re-check the surrounding landmarks. If the landmarks don’t match your expected location on the map, you alter your course based on where you know yourself to be on the map, and repeat until you arrive at your destination.

The PISO loop starts with a user-defined initial condition, which it uses to perform a “predictor” step to solve the momentum equation. Then the algorithm derives and solves the pressure equation, which it uses to perform a “corrector” step and then applies this “correction” to the momentum equation. Predict, correct, repeat.

Prediction of Resolution: Adaptive Mesh Refinement

The feature of CONVERGE that makes it uniquely useful for transient simulations is its Adaptive Mesh Refinement technique, or AMR. This technique uses a concept similar to the PISO algorithm: AMR looks at the field of existing conditions and estimates the magnitude of the sub-grid scales.

This sub-grid scale magnitude estimate is essentially an educated guess of the gradients in these conditions. Wherever a gradient is higher than a user-specified “sub-grid scale” value, AMR adds refinement until the gradient is small enough or until the user-defined maximum number of cells is reached. Predict, refine, repeat, automatically and with no user meshing!


The Future of Prediction

Since the inception of CFD, computers have been assigned the task of predicting the answer. But many CFD users have been burdened with the task of predicting the mesh refinement needed to get an accurate answer. This can be a tedious, frustrating process.

With the increasing availability, affordability, and efficiency of high-performance computational resources, predicting complex flow phenomenon using automatically adaptive mesh is clearly the present and the future of CFD. With CONVERGE’s automatic, Cartesian, cut-cell meshing and fully-coupled, Adaptive Mesh Refinement, this mesh refinement task has finally been relegated to computers. You no longer need to be able to predict and manually refine the mesh in areas where you think complex flow might be; CONVERGE’s AMR will automatically refine and adapt the mesh, at run-time, to capture this complex flow.

High-performance computational resources are now available to all CFD users, regardless of whether or not you have an in-house cluster. With CONVERGE in the CloudTM on Rescale cloud computing service, the future of prediction is in the cloud.

CONVERGE in the CloudTM on Rescale servers: harness the power of prediction!

Create an account and begin running CONVERGE in the CloudTM on Rescale.

This article was written by Convergent Science.


At Rescale, we’ve been venturing into the world of Facebook’s open source libraries with Immutable.js. Immutable.js is a library that provides immutable collections for javascript such as Set, Map, List, Stack, which are not available in ECMAScript 5. We found that these data structures improved the readability and sometimes the performance of our code (read on to see an example of this).

Another reason that we have decided to use Immutables was to eliminate the problems that arose due to the various ways of changing the UI “state”. Using Immutable.js you can replace your Plain Old Javascript Objects (POJO) with immutable maps, and every time something changes in your model your view will always have the correct reference to the latest status object.

To summarize, the benefits of using Immutable.js comes down to two points:

  1. Access to data structures such as Map, Set, List, Stack, etc
  2. Immutable design pattern that eliminates the problems associated with multiple states

In this article, I will show how OrderedSet can be used to simplify the code to illustrate the first benefit. I’ll start by introducing the original code, and before you read the code, here’s some context for the example.

We want to build a model for the UI that keeps track of selectedFiles across multiple pages, which are grabbed from the server as requested by the user. Because there could be thousands of files in total, the UI keeps only one page at a time, but stores all the files selected by a user across any number of pages. In this example, we specifically want to implement the “Select All / Deselect All” button, which selects/deselects the files that are currently shown.

Also note that the items could have already been selected from other pages, so you cannot simply add everything in displayFiles into selectedFiles, as that could potentially create duplicate copies in selectedFiles. Therefore, you need to compare the File objects using their ids instead of their references. To satisfy all the requirements, you end up writing something like this:

It may not be clear due to our liberal use of Underscore helper methods, but we’re essentially using a nested for loop to add or remove items in the selectedFiles array or the removing process, we’re iterating over the selectedFiles array from the end so that we can splice the array without affecting the iteration. Granted, it could be optimized with more helper functions and better bookkeeping, but it’s hard not to feel that we’re reinventing the wheel for implementing what is already known as a set.
With the use an OrderedSet, the code can be simplified to something like this:

It is definitely shorter, but there’s some magic to this approach that we haven’t fully disclosed yet. In the previous code, one of the crucial requirements for comparing files was to compare their ids instead of their references. In order to support this behavior with OrderedSets, we need to implement the hashCode method on the File class to define its uniqueness and the equals methods in a similar fashion that we do with classes that override equals and hashCode in Java. Here’s how this would look in our example:

Although, there is some extra code added to the class, the original method is much shorter and the readability of our code has been vastly improved. Considering that there are many more methods to be implemented involving File objects, the addition of hashCode and equals method on the File class will be well worth their lines.

Finally, in the controller we need to add the following watch statement since we have changed the type of selectedFiles into an instance of OrderedSet instead of a regular array.

Now this might make you wonder whether there’s any performance issues with rendering because every time we update the selectedFiles, whether it is adding a single item or removing hundreds of items, we are updating the reference of $scope.selectedFiles to a new array. But since the File objects themselves are still the same objects containing Angular’s $$hashKey property, Angular compares the items in the new array using the $$hashKey and makes the minimum required DOM updates. In fact, there are some performance gains due to simpler $watch statements when we have a lot of watchers for a huge data structure which doesn’t change very often. But it is also important to remember that there is some overhead involved with creating new data structures every time something changes in the model*.

There are situations in front-end development when you want those data structures(e.g. Map, Set, Stack, Queue etc) found in the java Collections API, which are not available in ECMAScript 5. In those situations, using Immutable.js can help you improve not only the readability of your code, but also the performance of your application. As always, it is not a panacea that works in all cases, but more often than not, it will prove to be beneficial.

*If you’re interested in learning more about the trade-off between the benefits gained with simple watch statements and costs incurred by creating new data structures, check out this article.

This article was written by Rescale.