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