At 2:29 PM +1000 7/12/04, Dan Newman wrote: >I'm working with the Australian DSTO Flight Systems Branch on develoment >of generic aircraft flight models. We are basing the datasets for this >work on the DAVE-ML DTD, with reasonable success so far. Our datasets >are used by loading directly into a DOM encapsulated in a C++ class >which performs function evaluations based on the XML dataset and returns >the results to the calling function. > >However, our work to date indicates an addition to the DTD would be >useful. I propose that the independentVarRef element be modified as >shown below: > ><!ELEMENT independentVarRef EMPTY> ><!ATTLIST independentVarRef > varID IDREF #REQUIRED > min CDATA #IMPLIED > max CDATA #IMPLIED > extrapolate (neither | min | max | both) #IMPLIED > interpolationType CDATA #IMPLIED > interpolationOrder CDATA #IMPLIED >> > >The justifications for this change are: > >For tabulated data in any form, the type of interpolation/extrapolation >applicable should be dependent on the data, not on the software in use >to interpret the data. It is therefore appropriate to include >interpolation instructions in the XML dataset. > >A variable may be interpolated differently in different functions within >the same dataset. Interpolation instructions therefore belong in the >independentVarRef rather than in the variableDef. An alternative would >be to include the interpolation instruction in the bpRef attributes for >each function, if that was thought preferable. > >Examples of the most common entries for these attributes are: > >interpolationType="polynomial" >interpolationOrder="1" > >which results in linear interpolation in the relevant degree of freedom, >with continuity of the function, but not of its derivatives, across the >breakpoints. Setting order to "0" allows discrete values, while higher >order can be chosen if required for rapidly-changing data. > >Alternative interpolation types can represent different methods, such as >"c-spline", or different choice of basis functions, such as "legendre". > >In future, it might also be useful to add further options to the >"extrapolate" attribute to determine whether the extrapolating basis >function is the same as that used for interpolation. > >We await with interest any comments or suggestions.
Dan, This is a good idea we could easily adopt if there is sufficient interest. In my experience, almost all real-time simulation facilities use first-order linear interpolation (equivalent to your polynomial/1 example) for piloted simulations. 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. 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. 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? 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? Let's discuss this further. I think text-based information exchange may rapidly become somewhat limiting :) -- Bruce -- Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch 18C West Taylor Street MS 132 Airborne Systems Competency NASA Langley Research Center Hampton, Virginia 23681 More info about DAVE-ML: <http://dcb.larc.nasa.gov/utils/fltsim/DAVE> Simulation standards discussion listserv mailto:[EMAIL PROTECTED]