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?" is that it is the inertial velocity (component) of the reference point in the vehicle (which our standard will clarify to be the CG) in the specified axis. Your question below involves "EGEVelocity_ms_1" as an example. You may confused partially because "EGEVelocity_ms_1" makes no sense, our naming convention is wrong. N,E,D does not make sense for most axis systems and we must change it to X,Y,Z. For example, in the GE system the axis system origin is at the center of the earth rotates with the earth about the Z axis. X and Y have no relation to N,E,or D. With that corrected let me continue. So your question is now "velocity of what wrt what?" for "YGEVelocity_ms_1" For non-vehicle carried systems (GE for example) our convention is accurate. YGEVelocity_ms_1 means velocity of the vehicle cg relative to the GE origin along the Y axis system, the Y component of the velocity. Since the GE origin is at the Earth's center, this variable happens to be velocity relative to the Earth's center. Also, since the axis system rotates in this system, even when the vehicle is moving at a constant speed in a straight line (inertially), the X,Y and Z GEVelocity will all be changing. However, if the reference system is not at the center of the earth or a point on the earth (FE for example), then that may not be the case. This convention also works for other planets and moons, etc. So I think our convention is correct in general for earth or other celestial body relative systems, or more generally, non vehicle carried systems. However, for some vehicle carried systems, you must refer to the R-004 standard. For example: Body, Wind, AA and SA are all related and ultimately relative to the uniform airmass as in R-004 (R-004 does not say "uniform" but I have added for clarity.) VO is relative to the EI system and used for satellites. The VO axis system is a good example of the bigger issue. My interpretation of R-004 is that the user can define the VO system with respect to another system, logically such as a Mars based geocentric inertial axis system ( the mars version of 1.1.1), for example. Soooo...... I think there are several alternatives (other than the naming convention which I will fix). 1) Do we clarify the WRT issue in the axis system definitions? Yes I plan to add some discussion in the axis system table. 2) Do we simply say with more emphasis to refer to R-004? Yes, I will emphasize that R-004 is the normative standard. 3) Do we put the explanation above in the standard? Yes , before the reference table. 4) Do we put the ...WRT... Option in the variable naming convention? I am planning to do 1, 2 and 3. I worry about option 4 in that it encourages(?) deviation from the Normative standard, R-004. And many (most) WRTs do not make sense or are redundant. IT might make sense to indicate BodyWRTAirMass or BodyWRTI (Inertial since that has been seen and in space there is no airmass, but then in space the whole reason for Body, Wind, AA and SA axis systems goes away, I think). So is BodyWRTI really meaningless??? Regarding units ms_1, you are correct and I will change to make unambiguous. May simply eliminate milli... What do you think? Again, sorry to take so long to respond and I encourage further input from you. ========================================== Bruce Hildreth Science Applications International Corporation (SAIC) SAIC Technical Fellow Suite 200 22299 Exploration Dr. Lexington Park, MD 20653 301-863-5077 301-866-6701 (Direct) 301-863-0299 (Fax) Bruce.Hildreth@ saic.com www.saic.com -----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 <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, > "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. >> >> >> >