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 John Park.