> It's nice to be able to have backout routines for interpolation
> tables, as well, which can be extremely helpful in initialization
> code. For tables up to 3d with fixed independent indices (is this
> what you meant by 'grid', or did you mean fixed intervals?), this is
> pretty straightforward. Creating backout utilities for larger
> dimensions and varying indices can be difficult.

## Advertising

By gridded I mean that the table is uniform. For instance, for 3D tables there
are say,
ten rows and four columns, and the row breakpoints are the same for each
column, and vice
versa. And, the row and column breakpoints are the same for each of the third
axis
breakpoints, too.
You can have tables where each row of independent data may have different column
breakpoints, and the row and column breakpoints (defining a 2D table) could be
different
for each additional 2D table.
Available data doesn't necessarily fall into neat buckets.
> Also, if you've got more than 3 inputs to a lookup table, you've
> probably not done enough data reduction, and you're asking for
> headaches when tuning the model. Usually, you can uncouple the
> dependencies enough to avoid such a mess, using multiple, smaller
> tables
>
> Drew
A 3D table is nothing. Some sims I am aware of use 6 dimensional tables or more.
The trick is to use recursion where possible. I've been toying with the idea
where each
dependent "data" point in a 2D table is itself another table. That would make
the problem
manageable. Yet, the toughest part of that may well be data entry and
formatting - unless
one has - as we (JSBSim) do: a tool (DATCOM+) that writes your aerodynamic
tables for you.
:-)
Jon
--
Project Coordinator
JSBSim Flight Dynamics Model
http://www.jsbsim.org
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d