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