# 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?"
is that it is the inertial velocity (component) of the reference point
in the vehicle (which our standard will clarify to be the CG) in the
specified axis.

Your question below involves "EGEVelocity_ms_1" as an example.

You may confused partially because "EGEVelocity_ms_1" makes no sense,
our naming convention is wrong.  N,E,D does not make sense for most axis
systems and we must change it to X,Y,Z.  For example, in the GE system
the axis system origin is at the center of the earth rotates with the
earth about the Z axis.  X and Y have no relation to N,E,or D.

With that corrected let me continue.

So your question is now "velocity of what wrt what?" for
"YGEVelocity_ms_1"

For non-vehicle carried systems (GE for example) our convention is
accurate.

YGEVelocity_ms_1   means velocity of the vehicle cg relative to the GE
origin along the Y axis system, the Y component of the velocity.  Since
the GE origin is at the Earth's center, this variable happens to be
velocity relative to the Earth's center.  Also, since the axis system
rotates in this system, even when the vehicle is moving at a constant
speed in a straight line (inertially), the X,Y and Z GEVelocity will all
be changing. However, if the reference system is not at the center of
the earth or a point on the earth (FE for example), then that may not be
the case.  This convention also works for other planets and moons, etc.
So I think our convention is correct in general for earth or other
celestial body relative systems, or more generally, non vehicle carried
systems.

However, for some vehicle carried systems, you must refer to the R-004
standard.

For example:

Body, Wind, AA and SA are all related and ultimately relative to the
uniform airmass as in R-004 (R-004 does not say "uniform" but I have

VO is relative to the EI system and used for satellites.

The VO axis system is a good example of the bigger issue.  My
interpretation of R-004 is that the user can define the VO system with
respect to another system, logically such as a Mars based geocentric
inertial axis system ( the mars version of 1.1.1), for example.

Soooo......

I think there are several alternatives (other than the naming convention
which I will fix).
1)  Do we clarify the WRT issue in the axis system definitions?  Yes I
plan to add some discussion in the axis system table.
2)  Do we simply say with more emphasis to refer to R-004?  Yes, I will
emphasize that R-004 is the normative standard.
3)  Do we put the explanation above in the standard?  Yes , before the
reference table.
4)  Do we put the ...WRT... Option in the variable naming convention?

I am planning to do 1, 2 and 3.  I worry about option 4 in that it
encourages(?) deviation from the Normative standard, R-004.  And many
(most) WRTs do not make sense or are redundant.  IT might make sense to
indicate BodyWRTAirMass or BodyWRTI (Inertial since that has been seen
and in space there is no airmass, but then in space the whole reason for
Body, Wind, AA and SA axis systems goes away, I think).  So is BodyWRTI
really meaningless???

Regarding units ms_1, you are correct and I will change to make
unambiguous.  May simply eliminate milli...  What do you think?

Again, sorry to take so long to respond and I encourage further input
from you.

==========================================

Bruce Hildreth
Science Applications International Corporation (SAIC) SAIC Technical
Fellow Suite 200
22299 Exploration Dr.
Lexington Park, MD 20653
301-863-5077      301-866-6701 (Direct)
301-863-0299 (Fax)
Bruce.Hildreth@ saic.com     www.saic.com

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Jackson
Sent: Thursday, March 13, 2008 8:17 AM
To: Curtin, Robert (Contractor)
Cc: Aerospace Sim Standard discussion group
Subject: Re: arrayDef & draft simstd comments

Rob,

I need to find some time to review your wonderfully rich suggestions in
without it, a parser will have to count the number of <dim> elements to
determine how many dimensions are required. Plus, it serves as a check
to make sure the two counts match.

Also, I am trying to avoid names like dim1, dim2, dim3, etc... This
implies a parser would be limited in how many dimensions it is required
to look for (up to dim199?).

Good catch on the naming for the initialValue - it does need to be
consistent with the current element definition. And it may be a good
idea to reuse variableDef in place of a new arrayDef element. In this
case, the presence of a "dimensions" attribute (with a value other than
1) would clue the parser that the variable is not scalar.

for his consideration, and I expect we'll be getting back to you; I
think you have some very valid points from the perspective of an
implementer.

Thanks again, and enjoy your Fall (as we are enjoying Spring),

-- Bruce

On Mar 12, 2008, at 6:40 PM, Curtin, Robert (Contractor) wrote:

> Hi Bruce,
>
> You suggestion looks good. The "dimensions" attribute would be
> unnecessary, as it's defined by the number of <dim> elements, in the
> same way that a gridded table's dimensional size is specified by the
> number of <independentVarRef> (and also <bpRef>) elements.
>
> I'd keep <initialValue> 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 <variableDef> element, by adding the appropriate
> subelements & rules?
>
>

> 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:
>
>    <arrayDef name="myDataMatrixr_m" varID="myDataMatrix" units="m"
> dimensions="3">
>      <dim>2</dim>
>      <dim>6</dim>
>      <dim>3</dim>
>      <description>My Data Matrix is a 2x6x3 matrix; the last dimension

> changes most rapidly</description>
>      <initialValues>
>         111 112 113  <!-- the actual order is important, not the way
> the data is formatted -->
>         121 122 123
>         131 132 133
>         141 142 143
>         151 152 153
>         161 162 163
>         <!-- second plane shows another valid way of listing a 6x3
> matrix -->
>         211 212 213 221 222 223 231 232 233 241 242 243 251 252
>           253     261   262       263  <!-- whitespace is unimportant
> -->
>      </initialValues>
>    </arrayDef>
>
> 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
>
>> 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
>> Dave-ML dtd. First thoughts would be to include an element like the
>> "variableDef" maybe called "arrayDef" with attributes similar to the
>> variableDef, but with additional attributes defining the dimensions
>> for the array of data.
>>
>> For example:
>>
>> For a vector of size (4x1):
>> <arrayDef name="myDataVector_m" varID="myDataVector" units="m"
>> dim1="4">
>>
>> For a 2-D matrix of size (4x6):
>> <arrayDef name="myDataVector_m" varID="myDataVector" units="m"
>> dim1="4" dim2="6">
>>
>> For a n-D matrix of size (4x6x3x...):
>> <arrayDef name="myDataVector_m" varID="myDataVector" units="m"
>> dim1="4" dim2="6" dim3="3" ...>
>>
>>
>> The data associated with the array would need to be either stored as
>> a data table or computed using Math-ML expressions. It would also be
>> useful if an element of an array could refer to a variableDef or
>> another arrayDef (depending on the dimension of the array). I would
>> expect that if arrays were manipulated using Math- ML then the
>> interpreter (such as Janus) would need to manage the compatibility
>> checking  - that is outside the XML file.
>>
>> One of the significant advantages of having an array element within
>> Dave-ML would be the ability to encode matrix mathematics within the
>> XML file - via Math-ML. I would find this particularly useful when
>> processing axes transformation operations - eliminating the
>> requirement for addressing the components individually. Another use
>> would be the encoding of Inertia tensors and cg vectors as a single
>> variable instead of having a variableDef for each component. I am
>> sure there are many other uses.
>>
>> I await in anticipations for comments on this proposal.
>>
>> Geoff Brian
>>
>> Aircraft Performance and Flight Dynamics Air Vehicles Division
>> Defence Science and Technology Organisation
>>
>> Ph: +61 (0) 3 9626 7318
>>
>> 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.
>>
>>
>>
>