RE: arrayDef & draft simstd comments
Hi Bruce, Thanks for taking the time to look at this. I've been trying to follow R-004 (and ISO 1151) also, but I've found it's primarily focussed on flat-Earth, steady atmosphere models. So, we follow it where we can and try to extend it in a consistent manner. My biggest remaining concern is that we need to separate the coordinate system definition from the reference frame. To quote Peter Zipfel: "Coordinate systems have no origins" - they are three orthogonal directions "floating" in space. eg, a geocentric coordinate system might have one axis direction defined by a line from the Earth's centre through the North pole, but that doesn't mean the coordinate system has its origin at the Earth's centre - all the matters is the direction. Thus, we can (and commonly do) refer to the velocity vector of a missile WRT an aircraft, expressed in, say, the geodetic (alternatively FE) coordinate system. The origin and magnitude of the vector are expressed by velocityMissileBody (following vector subscript notation, so this is read Velocity of Missile WRT Body (aircraft)). The direction is expressed using a coordinate system, which may have nothing to do with the aircraft or missile. In this example, the coordinate system is fixed to the Earth frame, but it has no origin. The only origin that matters is that of the velocity vector, ie, a point on the missile frame. Your mention of BodyWRTI is another good example. In fact, this is exactly what we use in our high fidelity 6-DOF model equations of motion. Since Newton's laws are only valid in an inertial reference frame, the force equations are vdotBodyInertial = R/m + g. The coordinate system doesn't really matter. To simplify the equations, we solve most of them in the inertial coordinate system, eg, vdotBodyInertial_Inertial = ... However, for the rotational ones its convenient to express it in body coordinates: omegadotBodyInertial_Body = ... The states then go through a series of coordinate transformations and vector sums to get values wrt the Earth in various coordinates. Since we are only concerned with atmospheric flight, we choose the J2000 geocentric inertial frame as being close enough to a real inertial reference. For flat, non-rotating Earth equations of motion, we substitute the "Earth" frame for the "Inertial" frame, and substitute "Geographic" (FE) coordinates for "Inertial" coordinates. Some more examples of parameters we actually use are: velocityBodyInertial_Inertial, velocityBodyEarth_Geocentric, velocityBodyEarth_Geodetic, velocityBodyEarth_Body, velocityBodyEarth_Geographic, velocityBodyAirpath_Airpath, velocityBodyAirpath_Body, velocityBodyAirpath_Geodetic, velocityBodyAirpath_Geographic, velocityWindEarth_Geodetic, velocityTurbulenceAirpath_Body, angularVelocityEarthInertial_Inertial, angularVelocityBodyInertial_Body, angularVelocityBodyEarth_Body, angularVelocityAirpathEarth_Airpath It's hard explaining this via e-mail, so I hope it makes sense. With regards ms_1... Apart from dropping milli, I don't know, but I'll have a talk about it here and see if there are any more ideas. Cheers, Rob Rob Curtin QinetiQ Consulting Level 3, 210 Kings Way South Melbourne, VIC 3205 Tel: +61 3 9694 1000 Fax: +61 3 9694 1001 Email: [EMAIL PROTECTED] Web: www.QinetiQ.com.au -Original Message- From: Hildreth, Bruce [mailto:[EMAIL PROTECTED] Sent: Friday, 23 May 2008 4:35 AM To: Bruce Jackson; Curtin, Robert (Contractor) Cc: Aerospace Sim Standard discussion group Subject: RE: arrayDef & draft simstd comments Hi Bob Curtin: Am extremely sorry it has taken so long to respond, but I have thought long and hard on this (and have been busy on other things too). Thanks for your suggestions regarding axis system. I have some discussion on your thoughts and will tell you what I plan to change in the standard to help clarify things. You have brought up a few issues that must be clarified in the standard, both in naming and in axis systems. You have opened an area in the standard that must have some correction/clarification, but is hard to cover all aspects of the issue. You have also brought to light an error that must be correct in the axis naming convention. First, "ANSI/AIAA R-004-1992, Recommended Practice - Atmospheric and Space Flight Vehicle Coordinate Systems" is the normative standard for axis systems, and we are trying not to deviate from this standard. In some cases that document provides more insight as to your question of "velocity of what wrt what? [in your email below]" in R-004's figures. I think R-004 uses the underlying (and correct) foundation concept that all motion is inertially referenced unless specified otherwise. R-004 is just not abundandtly clear on this. So, the general answer to the question of "velocity of what wrt what?"
arrayDef & draft simstd comments
Hi Bruce, You suggestion looks good. The "dimensions" attribute would be unnecessary, as it's defined by the number of elements, in the same way that a gridded table's dimensional size is specified by the number of (and also ) elements. I'd keep singular to avoid confusion. I'd also carry across the optional "axisSystem" attribute, for use with arrays that define cartesian vectors/tensors. In fact, could we do all this using the existing element, by adding the appropriate subelements & rules? This leads to some other comments on the draft standard I had for your consideration - more to do with coding than DaveML: I think the standard needs to be more rigorous wrt identifying points/frames and coordinate systems in variable names/varIDs. An an example, our (ie, DSTO-AVD) simulations use the variable name "velocityBodyEarth_Body" to indicate the velocity vector of the Body (reference point on the body frame) wrt the Earth (ditto), expressed in the Body coordinate system (coordinate systems after the underscore). Similary, "positionBodyEarth_Geocentric" is the position vector of the Body reference point wrt the Earth reference point, expressed in the Geocentic coordinate system. We also use the convention that in the vector "velocityDerivBodyEarth_Body", the derivative is taken in the Body coordinate system. This is different to "accelerationBodyEarth_Body", where the velocity derivative would be taken in an Earth-fixed coordinate system. Our direction cosine matrices take the form "transform_BodyEarth" (DCM of Body axes from Earth axes). We use a lot of vector math in our code, but if you don't, you then have to add in the specific axis to the above vector names, eg, "xPositionBodyEarth_Geocentric". The current draft Standard is not very clear in distinguishing the coordinate system and reference frames/points. Actually, it often omits the frames/points, eg, their "EGEVelocity_ms_1". Yes, it's the East (or Y) component in the GE coordinate system, but velocity of what wrt what? This becomes important when you have inertial, earth, air (with turbulence), body and landing gear frames. A few examples in the list at Annex A.1 do define the reference frame, eg, "GEVelocityYRelativeToEarth", though in this case its breaking its own convention about where to put the "Y". As best as I can figure out, the correct Standard variable name should be "EGEVelocityRelativeToEarth_ms_1". This still doesn't declare that it's the velocity of the body (ie, vehicle), but we could fix it thus: "EGEVelocityBodyRelativeToEarth_ms_1". Personally, I think the "RelativeTo" is a bit cumbersome, but it works. However, this convention is not explicit in the guidance at 5.2.3: (prefix)_(variable source domain) )(Specific axis or reference) ( Axis or reference system)(Core name)_(units) We had to fix it by adding conventions to (Core name). As for units (groan now)... We've not been including units in coded variable names (since we force consistency and can switch computational units). However, we do convert to and from computational units when interacting with DaveML files. One minor error I spotted in the draft Std is that "ms_1" has two interpretations: "meters per second" or "per millisecond". Trivial, but enough to miss Mars. Cheers, Rob Rob Curtin QinetiQ Consulting on contract to Air Vehicles Division, Defence Science & Technology Organisation Tel: +61 (0)3 9626 7730 -Original Message- From: Bruce Jackson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 12 March 2008 11:20 PM To: Brian, Geoff Cc: Aerospace Sim Standard discussion group Subject: Re: Matrix and Vector definitions for DaveML Geoff, This is a needed improvement to DAVE-ML. My first thought is the arrayDef attribute should be something like 'dimensions="3"' and then a (set) of subelements that define the actual dimensions: 2 6 3 My Data Matrix is a 2x6x3 matrix; the last dimension changes most rapidly 111 112 113 121 122 123 131 132 133 141 142 143 151 152 153 161 162 163 211 212 213 221 222 223 231 232 233 241 242 243 251 252 253 261 262 263 I also need to think through a way to mux and demux from scalars, and how well this fits into MathML matrix operations. Have you guys been using this extension in any useful way? Incidentally, the mailing list is getting rejections from several dsto.defence.gov.au addresses, including yours: > A message addressed to [EMAIL PROTECTED] in distribution > list "simstds" has been rejected. I'm working on a new revision to the 2.0 release that will hopefully accompany the initial AIAA/ANSI Standard, but I don't think we'll be able to get arrays defined by then. -- Bruce On Mar 11, 2008, at 11:00 PM, Brian, Geoff wrote: > Hi all, > > I am gauging for interest in adding the ability to define a data > array element (such as a vector or n dimensional matrix) within the
RE: Re: Discrete interpolation attribute (was New version of DAVEfunc DTD 1.9b3)
The discrete option, as we originally intended it, was a nearest grid-point
option. The relevant code snippet from the Janus interpreter:
* allow for order 0 linear interpolation, i.e. take nearest discrete
* value on the grid.
*/
if ( 0 == functionIndependentVariableOrder_[ index ][ i ] ) {
if ( 0.5 >= frac[ i ] ) {
frac[ i ] = 0.0;
} else {
frac[ i ] = 1.0;
}
}
We only use discrete where the inputs are meant to be one of the breakpoints.
The "nearest" interpretation ensures we get the right answer if there is some
issue with a data precision-related error (though we would normally use integer
inputs anyway). However, I can also see the utility of a "threshhold" approach
as you have described (eg, ISA properties as a function of pressure altitude).
You could always shift the breakpoints to achieve the same thing, or use
MathML. I agree it needs to be clearly documented.
Regards, Rob
Rob Curtin
Ball Solutions Group
on contract to Air Vehicles Division,
Defence Science & Technology Organisation
Tel: +61 (0)3 9626 7730
Fax: +61 (0)3 9626 7705
[EMAIL PROTECTED]
-Original Message-
From: Giovanni A. Cignoni [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 19 June 2007 10:17 PM
To: simstds@larc.nasa.gov
Subject: Re: Re: Discrete interpolation attribute (was New version of DAVEfunc
DTD 1.9b3)
> so the independent values state where the function changes value.
>
> Nearest-neighbor would put the transitions exactly between the
> independent break points.
So at the end is just truncation vs approximation, but being in sync with names
is anyway important :)
Ciao,
Giovanni.
IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT
1914. If you have received this email in error, you are requested to contact
the sender and delete the email.
