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
04.06.06
Posted in Programming and People at 1:45 pm by Brooks
I’ve been thinking a lot about the idea of practicing programming lately, after reading Steve Yegge’s “rant” on the subject. His claim is that programming is a lot like playing guitar – just doing a lot of it doesn’t make you any better; you have to specifically do things that will improve them.
Dave Thomas suggests in his Code Kata post that one way of practicing programming is by solving small-but-complex algorithmic problems, and he has a list of suggestions.
In the shower this morning, I was thinking about a problem that would fit nicely in that list. I’m writing a complicated bit of code that takes the triangles in a triangular mesh and loads them into a data structure. It would be nice to test it by taking a given mesh and loading the triangles in various random orders, and that immediately leads to the classic card-shuffling problem: given a list of objects, how does one efficiently sort them into a random order?
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
03.18.06
Posted in Assorted Tinkering at 1:48 pm by Brooks
(This is a slightly-edited repost of an article I wrote elsewhere, back in 2004.)
Some time ago, I posted a comment on This Is Broken, noting my frustration with motherboard-mounted AC power jacks on laptops, and noting that I had fixed a couple of them by following some online directions. Several people asked me to explain further, and I decided it would be useful to write up a more detailed explanation of how I did it.
First, the keywords: My experience is with a Compaq Presario 1210 laptop (which is very similar to the Compaq 1600 series), and a pair of HP Pavilion xf235 laptops, but this should apply to most similar laptops; the advice is mostly generic.
The problem, in short, is that most laptops have their AC power jacks hard-mounted to the motherboard just like any other soldered-on component, and for many of them this is the only structural connection. Unlike most other components, though, power jacks regularly get yanked on when someone steps on the power cord or such, and the solder joints (or the mounting tabs, which after all are pretty thin metal) start to fatigue, and eventually they crack. At this point, the laptop will only charge if the plug is twiddled “just so” (if at all), and doesn’t work reliably.
The official solution, of course, is to replace the motherboard — which fixes the symptom, but not the overall design problem. On a laptop with a street value of $300, this is also not an economical solution. But it does mean that you don’t really have anything to lose if you toast the motherboard trying to fix it yourself.
So. Enough preamble. Here’s how I fixed the problem.
Read the rest of this entry »
Permalink
03.17.06
Posted in Computational Fluid Dynamics, Dissertation Research at 12:31 am by Brooks
(This is a continuation of Why Simulating Free-Surface Flow is Difficult, Part 1.)
In Part 1 of this series, I talked about why it’s difficult to do an accurate computer simulation of a single drop dripping from a faucet. That’s a very simple example of a free-surface flow, however, and many of the flows that are relevant to other scientific or engineering questions are far more complicated.
One general class of more complicated free-surface flows are “sprays”, also referred to as “spray flows” or “atomization” – a liquid is forced at relatively high pressure through a small nozzle (or set of nozzles), and when it comes out it breaks up into tiny droplets. Sprays are nearly ubiquitous in any handling of liquids; for instance, in my day-to-day life, I might take a shower in the morning (under a spray of water from the showerhead), wash the shower walls with a cleaner in a spray-bottle, use an aerosol spray can of cooking oil to oil the pan to cook my eggs in, and wash the pan using the spray attachment on my sink. My car has a fuel-injected engine, which means that there are nozzles in it that spray the fuel into the air intake. If I were to paint the (sadly rusting) hood on it, I’d use a spray can. The train that I take to work has a diesel engine; the term “diesel” means that in it the fuel is sprayed directly into the engine’s cylinder, where it burns immediately as it’s being sprayed in.
In every one of those cases, it’s important to get the spray “right”. The shower-cleaner, cooking-oil, and paint sprays need to provide an even coating on the walls without spraying any off to the sides. The shower head needs to produce rather large drops that act like rain rather than fog. The fuel injectors in my car need to produce tiny droplets that will evaporate quickly, while the ones on the diesel locomotive need to produce droplets of the right size to get to the middle of the cylinder before they burn up. Thus, it would be very useful to be able to simulate the spray that comes out of a new nozzle design, so that it can be tested and improved without needing to do costly experiments.
As an example to talk about, here’s a fairly typical spray that’s easy to photograph – water being squirted through the nozzle from a Windex® bottle. I should credit my wife for patiently helping me take the picture; it took quite a few tries before I managed to get the flash timed correctly with the spray!
(click on the photo for a larger version)
Read the rest of this entry »
Permalink
« Previous entries · Next entries »
