Header Bar Graphic
Shuttle Image and IconAerospace HeaderBoy Image
Spacer TabHomepage ButtonWhat is NASA Quest ButtonSpacerCalendar of Events ButtonWhat is an Event ButtonHow do I Participate ButtonSpacerBios and Journals ButtonSpacerPics, Flicks and Facts ButtonArchived Events ButtonQ and A ButtonNews ButtonSpacerEducators and Parents ButtonSpacer
Highlight Graphic
Sitemap ButtonSearch ButtonContact Button

Aerospace Team ONLINE

UPDATE #25 - June 5, 1998

PART 1: Cancelled Chats
PART 2: Grid Generation
PART 3: Subscribing & Unsubscribing: How to do it


I am sorry to inform you that the June 2, 1998 chat with Leslie Ringo was
cancelled due to lack of attendance and the June 10, 1988 chat with Craig
Hange has been cancelled as well due to his extended stay in the UK. Both
are willing to reschedule so check the schedule at

If you would like to suggest the best time and/or days for chats this
summer send email to slee@quest.arc.nasa.gov

[Editor's Note: David Saunders is a Numerical Software Engineer at Ames Research Center. He helps people like Steve Smith generate Computational Fluid Dynamic Models. Read his bio at http://quest.arc.nasa.gov/aero/team/saunders.html]


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


If this is your first message from the updates-aero list, welcome!

To catch up on back issues, please visit the following Internet URL:

To subscribe to the updates-aero mailing list (where this message
came from), send a message to:
In the message body, write only these words:
   subscribe updates-aero


To remove your name from the updates-aero mailing list, send a
message to:
In the message body, write only these words:
   unsubscribe updates-aero

Footer Bar Graphic
SpacerSpace IconAerospace IconAstrobiology IconWomen of NASA IconSpacer
Footer Info