On Mon, 2004-07-12 at 23:54, Bruce Jackson wrote:

> In my experience, almost all real-time simulation facilities use first-order linear 
> interpolation (equivalent to your polynomial/1 example) for piloted simulations.
Yes, although the increasing capabilities of computational hardware are
likely to change this aspect in future.  Our interest is not only in
real-time simulation, but the specific model which caused us to consider
this requirement includes a fairly sparsely-tabulated function which the
manufacturer specifies as linear in one variable and third order in
three other variables.  We have been using this sort of model with
linear interpolation in simulations running significantly faster than
real time and expect that our fairly unexceptional hardware will allow
us to continue running faster than real time if we implement low order
polynomial interpolation as well.

> But, this standard is intended to be used by more than just real-time 
> man-in-the-loop simulations; my personal interest is for flight control design and 
> stability analysis of the same vehicle models. We have often seen a need for 
> smoother interpolations (generally cubic splines) to improve the fidelity of the 
> linearized models that are extracted to do control design.
Yes.  We're also looking at using it for performance modelling, and it
seems to suit that application well.  However, as some of our
comparative performance data is fairly sparse, the higher order
capability is important there also (trying to avoid V-shaped drag

> I guess my concern is, does this interpolation specification need to be captured 
> with the model? It would seem to me that the specific application of the model 
> dictates how smooth to make the tabular non-linear data. So, the flight control 
> designer might put a smooth curve through every table, while the real-time folks 
> stick with 1st order for speed.
The choice of tabulation interval, or position of tabulated points for
ungridded data, can be affected by the order of the interpolation
expected.  The interpolation and tabulation processes are therefore
inter-related and I think should both be defined in the XML dataset.  If
the same dataset is used for different applications, the attributes
related to interpolation can be used or ignored as each modeller
prefers, but inclusion of the attributes at least lets the modeller see
the assumptions on which the data compilation was based.

> However, to show our willingness to accept thoughtful suggestions, I'd be glad to 
> add this to the next DTD. Would you prefer the interpolationType to be a closed list:
>     interpolationType (poly | cspline | legendre) #IMPLIED
> or an open-ended CDATA with implementation details spelled out in the reference 
> manual?
I'm still experimenting with how best to do this.  The closed list could
be used for a first cut, but we might need to change it as we progress. 
We might also choose to add some other basis functions (much later). 
I'll have to think about the details of the spec, but you're right that
some additional details on the fitting technique will be required,
particularly for higher order functions.  As we progress and determine
what works best for us, I'll develop the relevant pieces of the spec and
post it to the list for comments and suggestions.

> Also, a complete spec should (IMHO) give additional details on how to fit a 
> polynomial through the data. Just specifying the data and giving the order of the 
> fit does not guarantee the same polynomial coefficients will be generated, I don't 
> think, even for piece-wise polynomials.  How about Legendre basis functions - what 
> information is required to fit these?
> We are aware of some efforts to encode an entire non-linear function using a single 
> multi-order polynomial, but that's not what you're suggesting, are you?
I'm not suggesting that, but it might be possible to define such a
function using this technique.  The main benefit of using such a
function will not be a reduction in the number of values tabulated in
the dataset, but the ability to obtain continuous derivatives over the
function space.

> Let's discuss this further. I think text-based information exchange may rapidly 
> become somewhat limiting :)
I agree, but the DSTO guys involved (Geoff Brian and Jan Drobik) didn't
immediately see the cost-benefit advantage of a trip for me to Langley.


Reply via email to