Grid Generation

by David Saunders

Nov. 19, 1997

If you are interested in software (computer programming), a recent experience of mine may be of interest. It involves software for grid generation, an all-important aspect of CFD (computational fluid dynamics) which is in turn a vital tool for modern aircraft design.

Last week I faced one of the hazards of the job for people who write software utilities intended for reuse by others: a colleague had written a new application to convert a computational grid or mesh to a similar mesh with different numbers of points, and was perplexed by some bad-looking results. Reluctant to question the program he was using (my own), he was eventually forced to conclude that there must be an error. His plots of odd grid lines certainly indicated a serious glitch somewhere, much to my alarm, since the subroutines in question had been written in 1993 and have seen regular use since then with apparent success. However, there had been occasional hints of problems earlier for meshes with highly skewed (non-rectangular) cells, and sure enough, here was new evidence of an error. What was I to do?

First, I had to reproduce the problem. Therefore I asked my colleague for his dataset, which was a surface mesh panel on the forward fuselage of an aircraft, with an odd shape far from rectangular. Then I wrote a short program to read this mesh and interpolate a denser mesh on the surface it defined, using the offending subroutine, PLBICUBE (which stands for parametric local bicubic interpolation, with interpolation meaning filling in values between the data points). Depending on how I subdivided the mesh cells, results were either (mostly) okay or definitely peculiar. By Friday evening, with the glaring evidence in hand, I printed listings of PLBICUBE and its ancillary subroutines and took them home, hoping to get enough quiet time on the weekend to compare the software with the analysis notes I had conscientiously filed four years earlier. I did not relish the prospect, because I remembered all too well the awkwardness of the method and the intensive testing that eventually seemed, back then, to indicate correctness.

As feared, about four hours of study on Saturday (with our two-year-old and his Mommie paying a price by not having me with them while visiting family, as happens too often)--four hours of scrutiny of the theory notes and the listings revealed no suspicious coding error. Very depressing! I really needed to be at work, logged on to the computer, to look closely at what was going on with this unpleasant dataset. And I did have one clue: my notes contained a question that had occurred to me at the time: should I use the "p" and "q" values from the two dimensional search needed as part of the method to locate the proper cell, or should I use similar quantities that the theory seemed to be indicating? Sure enough, on Sunday, I found the answer: a "q" value that should have been 1.0 at the outer boundary was nowhere near that because the relevant data grid cell was significantly skewed. Simply deleting one line of code for p and another line for q, and thus using the values returned by the preceding 2-D search, was the fix I needed. Now, interpolated grid lines curving beautifully in two directions appeared on my screen. What a relief!

The lesson here is that testing must be done on many kinds of datasets, not all of which obscure possible errors. Generating good test data is a problem in itself, and mine had all been nearly rectangular enough to have largely hidden a definite mistake. Seeing nice looking plots of results is one of the rewards of this sort of work, and they had seemed fine back then. Now, seeing them look fine for this awkwardly shaped dataset is even more rewarding. But it cost me plenty of anxiety and (yet) another disrupted weekend. Computers have a way of ruling our lives. This was just one more instance of a hazard in the life of a software engineer. But believe me, the satisfaction of seeing good results makes it all worthwhile.