RE: arrayDef & draft simstd comments

[Curtin, Robert (Contractor)]

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?"

RE: arrayDef & draft simstd comments

[Hildreth, Bruce]

 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
depth, but I had a rationale for adding a "dimensions" attribute:  
without it, a parser will have to count the number of  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.

I'm passing the comments about coordinate frames along to Bruce Hildreth
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  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 consi

RE: arrayDef & draft simstd comments

[Linse, Dennis J.]

Geoff, et al.,

I have the following comments on this excellent proposal:

1) I still don't see the need for a "typeArray" attribute.  The presence
(or absence) of "dimensionDef" is sufficient for any parser to determine
the size of any array that may be present.

2) As far as using "typeArray" to help if there is a MathML calculation
(since MathML uses vector, matrix type attributes), I don't think this
solves anything because what if the typeArray said "vector" but there
were two  in the ?  Or what happens if it is a 3 (or
more) dimensional array?  Also, the MathML has the whole 
 ...  syntax that we don't want to get into
here...

3) As far as "typeData", I would suggest adding an explicit "boolean"
type in addition to the real and integer.  While nominally covered by
"typeData" with a "base" of 2, it is (or could be) such a common item
that it would be useful to be more explicit.  I'm not as sure whether to
use something separate, or use the MathML  and  for the
values.

4.0) I hope that this section from your example:


  3.0


doesn't mean that there are non-integer dimensions!  It's been too long
since I studied fractals, but I don't recall anything that would be too
useful in DAVEML-type simulations. :-)

http://en.wikipedia.org/wiki/Fractal
http://en.wikipedia.org/wiki/Fractal_dimension


Dennis
---
Dennis J. Linse, Aerospace Engineer
Science Applications International Corporation
+1-703-294-4449   
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian, Geoff
Sent: Thursday, March 27, 2008 2:01 AM
To: Aerospace Sim Standard discussion group
Subject: FW: arrayDef & draft simstd comments 

 
Hi all,

The following is an experimental scheme I have come up with that makes
minimal change to the dtd to add a capability for vector/matrices. The
major change is to the definition of the variableDef element.

I have added to following in the element definition:
 "dimensionDef?, (calculation | array)?"

Also I have added to following in the attribute list:
 typeData   (real | integer) #IMPLIED
 base   CDATA   #IMPLIED
 typeArray  (scalar | vector | matrix)  #IMPLIED"


The "dimensionDef" is used when listing the dimensions of the
vector/matrix.
The "array" is used to represent the associated data table for the
vector/matrix.

The "typeData" and "base" have been included to address Giovanni's wish
to have data types for each variable. This concept I have taken from
that used by MathML for the definition of "cn" and "ci" elements. The
"typeData" is a subset of that defined in MathML (having the
possibilities of integer | rational | complex-cartesian | complex-polar
| real | e-notation  [Default : real]). The "base" has an integer value
of between 2 and 36, with a default of 10.
The "typeArray" attribute is used to define whether the variableDef
represents a scalar value, or vector/matrix values. This is again
similar to the convention used by MathML for the "ci" element.




To support this, the following is also required.


 




My syntax may not be totally correct. I have attached a sample file on
how vector/matrices might look in XML using this scheme.

Supporting whatever scheme is agreed on through Janus will be the next
challenge.

Geoff



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.

RE: arrayDef & draft simstd comments

[Linse, Dennis J.]

Bruce,

I'm with Rob.  Any (good) XML parser automatically counts the number of
subelements of a particular type and returns that number when requested
(e.g. getLength() in Xerces-C used by Janus) or allows you to iterate
through the list without (e.g. "for i in vars:" in various XML modules
in Python).  The dimensions attribute would only add redundancy that
isn't helpful if it is correct and causes errors if it is wrong (or
maybe just confusion: if "dimensions" is 3 and there are only two 
elements, should the third dimension be assumed to be length 1?).

I do agree that  and not dim1, etc. is the way to go.

An alternative that makes it look a little closer (in style) to how
/ is used in  would be


  
 2
 6
 3
  
  
...

Although I don't know if that really adds anything useful.

Again, the parser will easily know the number of  elements, so it
will easily figure out whether it is a scalar or a vector/array.  Note
that the parser already has to count such things in the
/ system.


Of course the real fun of the vector/array will be the mux/demux,
subreferencing, and MathML connections.  Examples:

1) Can an initialValue of an array be one or more previously defined
variables? (scalars, vectors or arrays)

2) Can elements of an array be referenced by scalar variables?

   array:  eulerAngle_d(3)
   scalars: rollEulerAngle_d, pitchEulerAngle_d, yawEulerAngle_d

3) Just for fun: 0-based (C) or 1-based (Fortran) indices?

Dennis
---
Dennis J. Linse, Aerospace Engineer
Science Applications International Corporation
+1-703-294-4449  <mailto:[EMAIL PROTECTED]> 
-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 depth, but I had a rationale for adding a "dimensions" attribute:  
without it, a parser will have to count the number of  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.

I'm passing the comments about coordinate frames along to Bruce  
Hildreth 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  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?
>
>
[...]
>
> 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:
>
> dimensions="3">
>  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  
>  
>
>

Re: arrayDef & draft simstd comments

[Bruce Jackson]

Rob,

I need to find some time to review your wonderfully rich suggestions  
in depth, but I had a rationale for adding a "dimensions" attribute:  
without it, a parser will have to count the number of  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.


I'm passing the comments about coordinate frames along to Bruce  
Hildreth 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  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 sh