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

Reply via email to