It has long been the case that 3-dimensional tables are the limit - TopicsExpress



          

It has long been the case that 3-dimensional tables are the limit of what we can do in JSBSim. Over the past few weeks I have become aware of a way to do n-dimensional tables, with additional capabilities, too. Some lookup tables in simulation - particularly for aerodynamic data - can be four, five, six, or even more dimensional. Not too long ago, an interpolation function was added to JSBSim. It is called Interpolate1d. Interpolate1d returns the result from a 1-dimensional interpolation of the supplied values, with the value of the first immediate child element representing the lookup value into the table, and the following pairs of values representing the independent and dependent values. The first provided child element is expected to be a property. The interpolation does not extrapolate, but holds the highest value if the provided lookup value goes outside of the provided range. The format is as follows: {property, value, table, function} {property, value, table, function} {property, value, table, function} ... Example: If mach is 0.4, the interpolation will return 0.375. If mach is 1.5, the interpolation will return 0.60. velocities/mach 0.00 0.25 0.80 0.50 0.90 0.60 The above example is very simplistic. A more involved example would use a function in any argument (except the first). That means that the breakpoint vector can be variable - which would probably not be common - but more importantly the values in the lookup vector (second column) could be function table elements of 1, 2, or 3 dimensions. The arguments could even be nested interpolate1d elements. For example: velocities/mach 0.00 ... table definition ... 0.80 ... table definition ... 0.90 ... table definition ... Carrying this further: aero/qbar-psf 0 velocities/mach 0.00 ... table 1 definition ... 0.80 ... table 2 definition ... 0.90 ... table 3 definition ... 65 velocities/mach 0.00 ... table 1 definition ... 0.80 ... table 2 definition ... 0.90 ... table 3 definition ... 90 velocities/mach 0.00 ... table 1 definition ... 0.80 ... table 2 definition ... 0.90 ... table 3 definition ... The above effectively gives a five dimensional lookup table. It would be big and messy, in practice, but there it is. :-) There is more, though. For very, very large aero databases there might be times when some aero coefficients do not need to be calculated. For instance, ground effects aero coefficients only need to be calculated close to the ground. Why waste CPU cycles when the ground effects do not contribute to the aero forces and moments? We can employ the ifthen element to bypass expensive computations. The ifthen element works as follows: If the value of the first immediate child element is 1, then the value of the second immediate child element is returned, otherwise the value of the third child element is returned. {property, value, table, or other function element} {property, value, table, or other function element} {property, value, table, or other function element} Example: if flight-mode is greater than 2, then a value of 0.00 is returned, otherwise the value of the property control/pitch-lag is returned. executive/flight-mode 2 0.00 control/pitch-lag In our case, we could write the 5-dimensional table lookup as follows, returning a zero unless the gear is down: position/altitudeMSL 90 ... 0 The above example is non-sensical in a way, but the format is correct. I have used this approach and it works well. Performance-wise it is good because the tables do not get executed unless absolutely needed in the lookup.
Posted on: Mon, 10 Jun 2013 03:07:21 +0000

Trending Topics



Recently Viewed Topics




© 2015