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 <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.

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

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,

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


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

   <arrayDef name="myDataMatrixr_m" varID="myDataMatrix" units="m"
     <description>My Data Matrix is a 2x6x3 matrix; the last dimension
changes most rapidly</description>
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

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

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.

Reply via email to