> 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.

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 
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 
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.

Project Coordinator
JSBSim Flight Dynamics Model

Flightgear-devel mailing list

Reply via email to