03.03.06

Why Simulating Free-Surface Flow is Difficult, Part 1

Posted in Computational Fluid Dynamics, Dissertation Research at 10:08 pm by Brooks

“Free-surface flows” are fluid flows that involve a surface that can move freely in response to the flow, such as the surface of the ocean, which is moved by the waves. This is contrasted to flows where all of the surfaces are fixed, such as water in a rigid pipe – or, alternately, a submarine deep under the ocean, where the only relevant surfaces are the rigid surfaces of the submarine which can only move as a solid piece.

As an example of a simple free-surface flow, consider water slowly dripping from a faucet. The surface of water across the bottom of the faucet moves downward, forming a drop, which eventually becomes heavy enough to fall and break off. I’ll use this to illustrate a couple of the reasons why computer simulations of free-surface flows are difficult.

(click on the photo for a larger version)

How Most Fluid-Flow Simulations Work

First, consider how a computer simulation of a fixed-surface flow works. The physical fluid flow is made up of the motion of a vast number of molecules – so many that in most cases the fluid is essentially continuous, and can be thought of as having a velocity (and a pressure, a density, and other properties) at every point within the fluid. The set of all of these velocity values at all of the points in the fluid is called a velocity field. Because there are an infinite number of points, a field contains an infinite amount of information. However, a computer program can only deal with finite amounts of information. Thus, we make an approximation: instead of calculating the velocity at every point in space, we only calculate the velocity at a few points, and approximate the velocities at all the other points with some sort of smooth interpolation between the points where the velocity is actually calculated.

This, of course, is only an accurate assumption if there is nothing interesting going on that’s smaller than the spacing between the points. If there is something interesting that’s small enough to hide between the calculated points, then the smooth interpolation will be incorrect, and the computation will not be a good match for the physical world.

Simulating Surfaces is Difficult

Now, if we look at the dripping faucet, there’s one very important aspect of the flow that is likely to be smaller than the spacing between the points – namely, the surface between the water and the air. This surface is only a few molecules thick, and so unless there are a vast number of points spaced only a few molecules apart through the entire region, there will be almost certainly be places where one point is on one side of the surface, and the next point is on the other side. The assumption that the flow is smooth and uninteresting between the points is completely wrong here.

It turns out that this problem isn’t quite as bad as it appears. If the calculated points are spaced closely enough that everything about the surface other than its thickness – in particular, its radius of curvature – is considerably larger than the spacing between the points, then it’s possible to keep some information at each point (for instance, the distance to the nearest part of the surface, or the fraction of the nearby volume that’s water) that will contain enough information to determine where the surface goes. Alternately, we could add some more points that are directly on the surface and are moved with it, and keep track of the surface that way.

Breaking Surfaces are Even More Difficult

There’s another problem, though, and this one is much harder to solve. In the time between the second and third pictures, something important happens to the surface: it breaks into two surfaces – one around the large drop at the bottom, and one around the column of water above it. Somewhere in the middle of that process, there was a point where it was stretched into a very very small filament between the drop and the column, and then this tiny filament broke. Moreover, the details of how that filament broke are fairly important; the timing determines when the end of the column of water starts pulling back up towards the faucet, and the actual breaking is responsible for the waves that are visible near the end of it. And those are both directly responsible for how it breaks into all the smaller drops in the last picture.

(And how does that filament physically break, you might ask? What shape-changing process allows it to do that? It turns out that it does this by a smaller and faster version of the same process — at some point in the middle of the filament, it becomes very narrow and stretches out into an even smaller filament, which very quickly breaks by an even smaller and even faster version of the same process. This happens so fast that it’s not exactly clear from experiments how it ends, but after a few recursions of this the column should be small enough that individual molecules would become important, and then it’s a much simpler matter of the breaking of a couple of atomic bonds between water molecules.)

So, the problem is this: accurately simulating what happens with all of those tiny filaments, if we try to do it in the usual way, requires having lots of very closely spaced computed points in them and near them to contain all the information about what they’re doing. And those points would have to be positioned and moved automatically, since there’s no way to know ahead of time (before we do the simulation) where exactly they’re needed. This turns out to be a remarkably complicated process, and even if the points are positioned in a very efficient way, it’s still quite a lot of points just for a single dripping faucet.

There are a couple of other ways to deal with this. One of them is to use some other more complicated way of representing the tiny filaments in the computer simulation, which is better suited to this particular part of the calculation than using individual points is.

The other method is to essentially ignore the problem; instead of calculating the actual process of breaking, one can simply assume that anything that’s too small to be calculated with a given computation is irrelevant. Sometimes, this is true – but even when it’s true, the simulation is only useful as a believable prediction if we’ve proven that it’s true for the particular situation that we’re simulating, and proving that raises other difficulties.

Permalink