11.21.06
Posted in Computational Fluid Dynamics, Dissertation Research, Tex, LaTeX, and ConTeXt at 2:04 pm by Brooks
The 2006 annual conference of the American Physical Society’s Division of Fluid Dynamics just ended a few hours ago, here in Tampa. As usual, I’ve put the slides from my talk up on dpdx.net/research/papers. Direct links: abstract, Slides in PDF form, and ConTeXt source for the slides. It’s a fun conference; unlike most, the talks are only ten minutes long, so it’s pretty easy to hit information overload by the end.
I’ll post some more about these results once I get home. I’ve been working pretty hard on this for the last few months, and haven’t had time to post much about it here, but things should be a bit less hectic soon. My code is finally producing results (luckily just in time for the conference!), and the results are considerably more dramatic than I was expecting — a pleasant surprise!
Permalink
10.06.06
Posted in Computational Fluid Dynamics at 9:45 pm by Brooks
This week’s big news in fluid flow simulation is Penny Smith’s existence proof for smooth solutions of the Navier-Stokes equations. (See also this in-depth explanation of the proof, and various other mentions of it here, here, and here.)
(Update: Regrettably, the article has been withdrawn due to a “serious flaw”. The piece described below is still interesting, however.)
The question that she’s solving is this: Given an infinite three-dimensional domain with arbitrary initial conditions, does a smooth solution to the Navier-Stokes equations (which are the equations describing the flow of water, air, or other fluids) exist on that domain for all future time? This problem was considered one of the most important open questions in mathematics by the Clay Institute, who are offering a one million dollar prize for a solution. It’s of some physical relevance directly, since if it’s not true then either there are cases where the Navier-Stokes equations don’t describe physical reality or else physical reality can behave in surprising ways. The greater significance, though, is that it and the methods that are used to prove it will be useful in further mathematical understanding of this particularly difficult problem.
Even though this is an existence proof and not a constructive one — which means that it proves that a solution exists, but does not provide an analytical method for finding one — there are some interesting construtive portions to the proof. Specifically, she shows that the solutions to the Navier-Stokes equations can be expressed as the limit of a set of hyperbolic equations. There is some interesting physical and computational relevance to how that works, which I thought would be interesting to more mathematically-inclined readers.
To start with, the Navier-Stokes equations are differential equations in four variables — pressure (p) and three directional components of velocity (ui, for i=1, 2, or 3). They look like this:
(Note that, in this notation, each term has an implicit sum over indices that appear twice in the term; thus, the second term in the first equation and the first term in the second equation are implicitly summed over
k. As
i appears only once in each term of the first equation, there isn’t an implicit summation over it, and thus that represents a set of three equations, one for each coordinate direction.)
There are some interesting features of this set of equations. First, there are four equations and four unknown variables, so it’s a closed set. However, if we start matching up variables with equations on a one-to-one basis, we find that the first three equations match up neatly with the three components of velocity, leaving the last for the pressure — even though it doesn’t actually have pressure in it (much less a time-derivative of pressure)!
What happens, then, is that at any point in time, the first three equations describe the time derivative of the velocity, as a function only of the local field at the current time (that is, they’re hyperbolic). This means that in these equations information travels across the domain at a finite rate, which is a very nice feature computationally; one can compute a solution at each grid point without needing to know the solution everywhere else. It’s also handy mathematically.
The fourth equation, though, messes all of this up. What it says is that the pressure needs to be chosen such that this velocity condition is satisfied everywhere. Physically speaking, if the velocities would be trying to compress a certain spot, the pressure there gets increased to counteract that, so it doesn’t compress. This isn’t a local constraint, because it’s the derivative of the pressure that affects the velocities, and so a change in pressure in one place causes immediate changes throughout the whole domain — essentially, the speed of information transfer is infinite. In a computational simulation, the vast bulk of the time is usually spent taking care of the pressure.
So, how does Penny Smith’s analysis approximate this by a set of hyperbolic equations? There are two parts to that. The first part is that she needs a set of first-order equations for her analysis, and this contains a second order term. Fixing that is straightforward, we simply introduce more variables, and a mathematical identity. The (nine) new variables are the components of a “viscous stress tensor”, defined as:
(That’s nine equations, one for each combination of
i and
k). (Also, for the fluid mechanicians: it’s not quite the viscous stress tensor, I know; there are terms left out that sum to zero.) Then, the first three equations can be rewritten as
This gives a set of thirteen first-order differential equations and thirteen unknowns.Now, for the hyperbolic part. I’ll start with the pressure equation, since that’s the one that has historically been a problem, but in this first-order formulation the stress-tensor equations also are not hyperbolic. To be a hyperbolic equation, this needs to have a time derivative of pressure in it. So, suppose we just add one, multiplied by an arbitrary constant (denoted ?):
If ? is zero, this is the same as the initial equation, but if ? is greater than zero, this and the other three initial equations form a hyperbolic set. Thus, if we take a set of ? values that converge to a limit of zero, we get a set of solutions of hyperbolic equations which converge to a solution of the initial non-hyperbolic equations.It turns out that this has physical significance — what happens is that, if the velocities are trying to compress a certain spot, the pressure there still goes up, but not immediately, and so things do get compressed but only a limited amount. This is exactly what happens in “compressible” flows, such as air flows at high speed, so it’s a phsyically meaningful problem. In effect, there’s a “relaxation time” — a finite amount of time that it takes for the pressure to respond to a given input; this relaxation time is proportional to ?, and so what we’ve done is taken an equation with a zero relaxation time and given it a finite nonzero one.
This suggests a rather simple computational method: solve the problem with a small but non-zero value of ?, and thereby obtain a solution that’s close to the desired one. This used to be a fairly common method, because hyperbolic problems are relatively easy to solve, and it’s called “artificial compressiblity”. It works reasonably well in some cases, although as ? gets closer to zero, the rates of information transfer around the domain get faster, and so the equations take more work to solve computationally. And, of course, if you use a larger ?, the rates of information transfer get slower, and so the solutions aren’t as close to the real solution. But it’s reasonably good for some problems.
Now, in Penny Smith’s case with everything in first-order equations, there are some additional equations that aren’t in hyperbolic form, so she does exactly the same thing to those equations, adding a time-derivative term to those as well:
In the computational situation, this isn’t necessary; the stress tensor can be calculatated from local data and doesn’t have problems of global dependencies, so there’s no need to add the nonzero relaxation time to these equations. However, it’s important for simplifying the mathematical analysis. (And it’s an interesting question whether it might be useful in computations as well; there are some advantages to working with things that are mathematically simpler.)So, that’s pretty much what’s going on with that part of the analysis. From there, the proof then goes off into two additional — and far more complicated — parts. First, there’s a proof that smooth solutions to these sets of first-order hyperbolic equations exist for all time, given a sufficiently smooth set of starting conditions. Then, there’s a reference to a proof from 25 years ago by John Heywood, which showed that smooth solutions to the Navier-Stokes equations exist at least for a finite time, and some analysis that shows that his solutions can be used to provide appropriate starting conditions for the first half of the proof. And, finally, there’s a small bit to tie everything together and show that the fact that the hyperbolic equations have smooth solutions means that their limit is also smooth. QED.
(Note: Equations in this article were typeset with MimeTeX.)
Permalink
05.06.06
Posted in Computational Fluid Dynamics, Dissertation Research at 10:21 am by Brooks
I just added the slides from my presentation at the 58th annual November meeting of the APS’s Division of Fluid Dynamics to my publications page. This is largely a modified version of the presentation I gave at the ILASS meeting last May.
Presentations at APS meetings are only 10 minutes long, instead of the 25 at most other conferences, so these slides are much tighter and more concise than the ILASS slides. I think there are definite advantages to the format; most of the presentations still seemed to contain all of the critical aspects of the research, and most of what seemed to get cut was excessive belaboring of points, and recitations of the same justifications and basic background that we’ve all heard dozens of times before. And, of course, it means that there’s time to see more than twice as many presentations in a day; when the conference packs over a thousand talks into a three-day block, that’s quite important.
One unfortunate thing about the APS DFD meeting is that the talks don’t come accompanied by papers that one can look up and read afterwards. For my presentation, though, my paper from the ILASS meeting covers most of the same results.
Oh, and at some point I’ll work out an appropriate Creative Commons license for this stuff. In the interim, if you want to borrow one of the slides or figures for something, just send me an email.
Permalink
04.10.06
Posted in Computational Fluid Dynamics at 11:42 pm by Brooks
After a couple of weeks of work (in and among the other things I was doing), I’ve finished a releasable version of the OpenFOAM-1.3 Cygwin port. I’ve stuck it all in a source .tar.gz file and a compiled-binaries .tar.gz file, and updated the openfoam-cygwin page with links and updated instructions and things. There’s also a compiled-binary version of gcc 4.1.0 up there to go with it, for people who’d rather not compile their own – theoretically, this time around, OpenFOAM shouldn’t need a specially-configured version like it did of 4.0.2 (to get around a gcc bug), but I couldn’t find any binaries already online to copy, so I had to make my own again.
The basics of the port were pretty much the same as last time. There are a couple of key problems to work around to get OpenFOAM to compile on Cygwin. First, it’s written for a case-sensitive filesystem, and has files named “Vector.H” and “vector.H” in the same directory, and suchlike. This clashes when one tries to unpack the source distribution on a case-insensitive filesystem, and then when one goes to compile it, the #include lines in the source files pull in the system’s “vector.h” file instead of either of them. Fixing this is a tedious but trivial matter of renaming all the relevant files, and fixing all the #include lines. Someday I’ll write a script for it, but this time I did it by hand with the disk-search-and-replace in my text editor.
The more interesting problem involves how dynamically-linked libraries are compiled and linked on Windows versus Unix and Linux. OpenFOAM is, functionally, a big set of libraries that get linked into application-specific (and often user-written) wrapper programs. Most of the core functionality is in a libOpenFOAM library, although the parallel-processing parts are off in a libPstream library. This allows for different parallel implementations to be used depending on which of various libPstream libraries is actually used at runtime, while having only one version of the libOpenFOAM library. Unfortunately, this is written with a bit of a circular dependence; libPstream uses a lot of data types defined in libOpenFOAM, while libOpenFOAM needs to link to libPstream.
Read the rest of this entry »
Permalink
03.28.06
Posted in Computational Fluid Dynamics at 1:25 pm by Brooks
The good news: Someone’s using my Windows port of OpenFOAM. It’s nice to know that it’s actually going to be useful to somebody.
The bad news: I know this, of course, because they’ve posted a bug report to say it doesn’t work for them.
Turns out that a large part of the problem was fairly obvious in hindsight. The original OpenFOAM package contains environment setup files for both bash and tcsh, and I had modified them both for use under Cygwin. However, since I use tcsh, I had completely neglected to test the bash scripts, and there were several typos in one of them. The other problem was that, since the OpenFOAM port uses a local copy of GCC 4.0.2, rather than the Cygwin system copy of GCC, this user had decided to uninstall his system GCC to avoid any possible confusion – and thereby flushed out a bug where the make system was hardwired to use the C preprocessor installed as /bin/cpp, rather than the one in the local copy of GCC. This one dates back to the original Linux version of the software, so I’ve in turn filed a bug report on that.
Aside from that, there were a number of complications that amounted to reminders that, whenever the build process goes awry, it’s important to clean up any incomplete results so that they won’t perpetuate the problem after the actual bug is fixed.
So, it looks like everything is fixed now, but I’m waiting for a final confirmation that it all works before I push all the bugfixes into a new version and post it.
Permalink