> 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 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 [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
