Test message resend - ignore please

[Bruce Jackson]

I'm attempting to hook up this mailing list <[EMAIL PROTECTED]> to the Mail Archive 
<http://www.mail-archive.com> web site, so future messages will be accessible via the 
web...

This is a test message - feel free to delete.

--Bruce Jackson
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132Airborne Systems Competency
NASA Langley Research CenterBuilding 1192C, Room 149
Hampton, VA 23681-0001scud://N 37 05'31.7" W 76 22'55.1"
http://dcb.larc.nasa.gov/DCBStaff/ebj/ebj.html "There is no try"

Confidence interval

[Bruce Jackson]

Title: Confidence interval


During this month's working group telecon, the topic of
confidence intervals for aero data came up. I think I misspoke then
about using a single value for "confidence," and wanted to
clarify my thoughts.

The current draft AIAA standard for simulation data
exchange

ange_Jan2003.pdf>

recommends carrying, for any data table so desired, a set of
points showing the 95% confidence bound (with the table values
themselves being the nominal value to use if not performing a Monte
Carlo or stress test).

I take this to mean, for a gaussian or normal distribution, to be
about 1.645 standard distributions.

A more common statistic would, I think, to give the +/- 3 sigma
value. This corresponds to 99.86% confidence that the data lie within
the bounds given. Alternatively, we could adopt a single sigma
boundary, which works out to 84.1% confidence interval.

Someone check me on this - my statistics background is a bit
dusty.

I think we should also support a standard with a selectable
gaussian (bell curve) or uniform (flat line) distribution, where the
actual value of the parameter is believed to lie in equal probability
anywhere between the two boundary values. 

These two changes to the draft simulation exchange standard
would, I think, move us closer to industry practice for Monte Carlo
simulation results, in my limited experience.

Any opinions welcomed.

--Bruce Jackson
-- 

Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control
Branch
18C West Taylor Street MS
132   
Airborne Systems Competency
NASA Langley Research
Center    Building 1192C, Room 149
Hampton, VA
23681-0001    scud://N 37 05'31.7" W 76 22'55.1"
http://dcb.larc.nasa.gov/DCBStaff/ebj/ebj.html
"There is no try"

RE: Confidence interval

[Bruce Jackson]

Title: RE: Confidence interval


At 4:58 PM -0400 9/2/03, Hildreth, Bruce wrote:
Hi Bruce,
see embedded comments
-Original Message-
From: Bruce Jackson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 3:37 PM
To: [EMAIL PROTECTED]
Cc: Bruce Hildreth
Subject: Confidence interval

During this month's working group telecon, the topic of
confidence intervals for aero data came up. I think I misspoke then
about using a single value for "confidence," and wanted to
clarify my thoughts.

The current draft AIAA standard for simulation data
exchange

ange_Jan2003.pdf>



recommends carrying, for any data table so desired, a set
of points showing the 95% confidence bound (with the table values
themselves being the nominal value to use if not performing a Monte
Carlo or stress test).
I[Hildreth,
Bruce]  thought 3 sigma was 95%.  However, the
confidence interval info should support symmetric and assymetric
distrubutions of any confidence,  We should add to the
DTD;
 
1)global distrubution
specification definition  ( ex. normal, binomial, uniform...
etc)
2)global sigma (accuracy)
specification (ex. 1, 3, 5 whatever... etc)
 
and the related two DTD
for a specific function that overrides the global
definition
 
I do not believe that the
spec should require a specific definition, but needs to accomodate
whatever the data is.  So I think we agree
 
Note:  for symmetric
distributions only one value needs to be set,  Only for
assymetric distributions do you need the + and the
-.


I am posting this reply to [EMAIL PROTECTED] so others may
benefit from your wisdom, Bruce H. :).

I don't see an exceptional utility to a global distribution
specification; this is only a small amount of data to append to each
table. I agree we need both a distribution specification and an
accuracy specification (the popular "six sigma" will be the
favorite of management types!) but I think it is best left to reside
with individual tables.

-- 

Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control
Branch
18C West Taylor Street MS
132   
Airborne Systems Competency
NASA Langley Research
Center    Building 1192C, Room 149
Hampton, VA
23681-0001    scud://N 37 05'31.7" W 76 22'55.1"
http://dcb.larc.nasa.gov/DCBStaff/ebj/ebj.html
"There is no try"

C++ XML Parser of choice

[Bruce Jackson]

Does anyone on the list have experience using an XML parser with C++? If so, can you 
recommend a decent set of parser tools?

--Bruce
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132Airborne Systems Competency
NASA Langley Research CenterBuilding 1192C, Room 149
Hampton, VA 23681-0001scud://N 37 05'31.7" W 76 22'55.1"
http://dcb.larc.nasa.gov/DCBStaff/ebj/ebj.html "There is no try"

Uncertainty modeling

[Bruce Jackson]

Title: Uncertainty modeling


Sim standards listserv subscribers:

I'm trying to get my hands around uncertainty modeling for
aerodynamic parameters / function tables.

In my experience, we may be required to support (in a future
release of DAVE-ML) variations/uncertainties/statistics about
individual aerodynamic parameters. So things like constants and
function tables will need to have embedded within their description an
idea of the statistical variation or uncertainty in the
parameter.

I'm thinking about being able to specify this uncertainty in
several possible ways:

1) as a possibly asymmetric limit, either multplicative (CL =
0.15 +/- 10%) or additive (CL = 0.15 +0.02/-0.01)

2) as an upper and lower limit function, with tables,
corresponding to the breakpoint values:

  alpha 
0 5
10  15
18 20

   CL  
0.0   0.01   0.023  0.034  0.044 
0.050

 upper lim  0.01  0.02   0.031 
0.038  0.046  0.062

 lower lim -0.01  0.00   0.020 
0.030  0.041  0.045

(also for multidimensional functions; the point is, three
tables would be required of identical dimensions)

3) as an upper and lower limit function, with a smaller set of
breakpoint (or possibly even smaller dimensionality) than the original
table

 CL table 
   Mach   0
5 10    20  
24
    0.0  0.01  0.02  0.04 
0.08 0.09 
    0.5  0.00  0.01  0.03 
0.07 0.08
    0.9  0.00  0.01  0.02 
0.06 0.08

CL uncertainty *multiplier* vs alpha only
  alpha ->  
0    15 25
 upper lim  0.1  
0.1   0.25
 lower lim -0.1  -0.1 
-0.30

so here the uncertainty is a function of alpha only, with
a different set of breakpoints, even though CL itself is a function of
alpha & Mach

The values can be specified as additive, multplicative, or
absolute numbers.

The values could represent 1-, 2-, or 3-sigma confidence levels
for a Gaussian/normally distributed parameter, or the values could be
absolute limits for a uniform distribution.

Any comments to the list, please ->
[EMAIL PROTECTED]

Thanks for your interest.

--Bruce Jackson
-- 

Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control
Branch
18C West Taylor Street MS
132
Airborne Systems Competency
NASA Langley Research
Center  Hampton, Virginia
23681
More info about DAVE-ML:

Simulation standards discussion listserv
mailto:[EMAIL PROTECTED]

Re: C++ XML Parser of choice

[Bruce Jackson]

At 1:43 PM -0700 10/16/03, Jeremy Furtek wrote:
> > Does anyone on the list have experience using an XML parser
>> with C++? If so, can you recommend a decent set of parser tools?
>
>I have been using the Xerces-C++ parser for an application, and it has been
>more than adequate.
>
>http://xml.apache.org/xerces-c/index.html
>
>I have also used expat.
>
>http://www.jclark.com/xml/expat.html
>
>The Xerces-C++ parser seems pretty complete. You can parse documents using
>either the SAX or DOM interfaces. (When using SAX, you provide callback(s)
>for XML element beginning and endings. The DOM interface builds a tree in
>memory of the entire document contents, which you can then "walk.") My
>favorite thing about Xerces-C++ is its support of XML Schema. You can
>provide the parser with an XML Schema file (which is like a DTD, only in XML
>format) and the parser will notify you if the document doesn't conform.
>
>Expat seems to be a more minimalist implementation. It is not a "validating"
>parser. It is written in C, and offers a SAX-style interface.
>
>If pure speed is important to you...
>
>(I am not saying that it should be. I only bring it up because it has been
>mentioned in this group recently.)
>
>you might want to look at the internal character representations used by the
>parsers that you consider. XML files can be encoded with 8 or 16 bit
>characters. The Xerces-C++ parser interface uses 16 bit characters,
>regardless of the encoding of the document. If I remember correctly, expat
>uses 8 bit characters. If all of your XML files are encoded in 8 bits, you
>might be able to realize a small performance gain by using a parser that
>takes advantage of this fact.
>
>Of course, if speed is that important, you could probably select a better
>format than XML.

At 9:30 AM -0500 10/15/03, Riley Rainey wrote:
>Hey Bruce,
>
>Our company uses Xerces-C quite a lot.  It does provide for different styles
>of programmatic access and my experience so far has been positive.
>
>At a previous company I worked with Microsoft's XML Parser and DOM (DOM ==
>Document Object Model, for those who didn't know); DOM access worked well in
>most cases, but MSFT requires that you embrace some form of COM programming
>style in your C++ code (e.g. ATL).
>
>Riley

At 10:25 AM -0400 10/15/03, York, Brent W.  CIV NAVAIR 4.3.2.3 wrote:
>Bruce,
>
>We've used MSXML and Expat. We use a wrapper library called "SAXinCPP," which is open 
>source thing you can find on the Internet. I think the guy who wrote it changed the 
>name to something catchier, though, since we started using it. If you want, I can 
>have our XML expert send what we have to you...
>
>_Brent

At 9:38 AM -0500 10/15/03, Jon S Berndt wrote:
>Hi, Bruce:
>
>Check out the FlightGear (www.flightgear.org) project for one example ("easyXML") and 
>perhaps ask a question on their developer list (or I can do that). For JSBSim, I 
>wrote a very limited parser in C++ that I use, but I've been wanting to evolve into 
>using a more capable parser - a *real* one.  Of course, for my project I need to 
>consider open source projects. There are two (as I recall): TinyXML, and eXpat - both 
>on the SourceForge web site:
>
>http://tinyxml.sf.net
>http://expat.sf.net (see the C++ wrappers links)
>
>Good luck,
>
>Jon



Thanks, Jon, Brent, Riley & Jeremy. I'd been eyeing Xerces-C++ but was not aware of 
the 16-bit (UNICODE, I guess) character representation. I might stick with it anyway 
since it seems like the right choice (open source, well-supported, and popular).

I've been using Xerces-J for a Java XML application, and am well satisfied with it; I 
wanted to see if maybe I was missing a better solution.

I'll look into the other suggestions (expat, easyXML, tinyXML, and SAXinCPP) but 
suspect MSXML is a Windows-only solution?

Thanks again for the rapid response!

--Bruce

New developmental revision 1.5b3 of DAVE-ML markup: DAVEfunc.dtd

[Bruce Jackson]

I will shortly post a new revision (beta 3) of DAVE-ML 1.5 to the Digital Aerospace 
Vehicle Exchange (DAVE) website (see signature for URL).

There is one new feature and one subtle one:

New: the DAVE-MLreference manual (available in both HTML and PDF) includes examples of 
the major subelements

Subtle: the [un]griddedTable element is deprecated in favor of [un]griddedTableDef 
elements; this combines nearly identical elements into one ([un]griddedTableDef) for 
future development. The original [un]griddedTable element is now marked as deprecated, 
and it is suggested that existing DAVE-ML models be updated to simply change all such 
elements to [un]griddedTableDef elements by simple rename.

I'm still receptive to ideas concerning my earlier e-mail on statistical properties of 
functions... I'll be tackling that next.

--Bruce Jackson
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://dcb.larc.nasa.gov/utils/fltsim/DAVE>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

New developmental version 1.6 of DAVE-ML

[Bruce Jackson]

Happy New Year, sim folk!

I've posted a new version (1.6, beta 1) of DAVE-ML to the Digital Aerospace Vehicle 
Exchange (DAVE) website (see signature for URL).

This new developmental version has an added 'uncertainty' element to better support 
statistics about any data representation, with the idea of better supporting the 
capability of doing Monte Carlo assessments using the simulation model. This feature 
is as yet unproven and untested, and will no doubt be subject to change.

The associated updated reference manual (available in PDF and HTML) on the web site 
discusses the new uncertainty element (see page 23 of the PDF or 

<http://dcb.larc.nasa.gov/utils/fltsim/DAVE/DTDs/1p6b1/Ref/ar01s06s03.html>

for more detailed information.

Feedback welcomed.

Shameless AIAA plug: DAVE is being developed in cooperation with the AIAA Modeling and 
Simulation Technical Committee. Support your technical organization's standards 
efforts!

-- Bruce Jackson, NASA Langley Research Center
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://dcb.larc.nasa.gov/utils/fltsim/DAVE>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

Beta version 1.7 of DAVE-ML DTD

[Bruce Jackson]

Simulation Standards discussion group subscribers:

I've posted a new version (1.7, beta 1) of DAVE-ML to the Digital Aerospace Vehicle 
Exchange (DAVE) website (see signature for URL).

This new developmental version has a new set of elements, 'checkData' etc. that allow 
inclusion of check case data with each model. This will support automated verification 
of proper implementation of the model for one or more specific sets of inputs.

The associated updated reference manual (available in PDF and HTML) on the web site 
discusses the new elements and gives examples.

Feedback welcomed.

Shameless AIAA plug: DAVE is being developed in cooperation with the AIAA Modeling and 
Simulation Technical Committee. Support your technical organization's standards 
efforts!

-- Bruce Jackson, NASA Langley Research Center
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://dcb.larc.nasa.gov/utils/fltsim/DAVE>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

Re: New member

[Bruce Jackson]

At 3:47 PM -0300 3/26/04, Carlos Eduardo Beluzo wrote:
>Hello, first a want to present myself.
>I'm Carlos and i'm gradueted in Informatics by the Universidade de São
>Paulo - São Carlos - SP - Brasil.
>Now i'm doing my MS on Aeronautics Engineering in the same university. My
>work will be part of a Flight Simulator. I'll implement a the equations that
>describe the dynamic and control of flight. So i was looking up on the WEB
>for informations or something intersting, then i found out this project and
>starts to read more about it because a liked it.
>
>But i'm writing because i foud this on DAVE-ML's site and got a little
>trouble:
>
>"We are also experimenting with being able to convert DAVE-ML files into
>HTML documents, using a Java-based tool known as eXtensible Something Linear
>Translation (XSLT)."
>
>XSLT wouldn't be Extensible Stylesheet Language-Transformation??

Carlos,

My apologies: your post somehow got lost in my in-box. So I hope this message will 
still reach you at school!

You are correct: XSLT is indeed as you quoted. I need to fix the DAVE-ML page to 
reflect the correct acronym definition.

At NASA we spend a lot of effort developing TLA's, but since this is a FLA, I was 
unable to process it using standard TLA tools and processes. That is why the 
definition escaped me when writing.

Thanks again for your post!

-- Bruce Jackson

P.S. TLA -> Three Letter Identifier. Thanks to JGB for the TLA 'TLA'.
--
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132Airborne Systems Competency
NASA Langley Research CenterBuilding 1192C, Room 149
Hampton, VA 23681-0001scud://N 37 05'31.7" W 76 22'55.1"
http://dcb.larc.nasa.gov/DCBStaff/ebj/ebj.html "There is no try"

Re: proposed addition to DAVE-ML

[Bruce Jackson]

At 2:29 PM +1000 7/12/04, Dan Newman wrote:
>I'm working with the Australian DSTO Flight Systems Branch on develoment
>of generic aircraft flight models.  We are basing the datasets for this
>work on the DAVE-ML DTD, with reasonable success so far.  Our datasets
>are used by loading directly into a DOM encapsulated in a C++ class
>which performs function evaluations based on the XML dataset and returns
>the results to the calling function.
>
>However, our work to date indicates an addition to the DTD would be
>useful.  I propose that the independentVarRef element be modified as
>shown below:
>
>
> varID IDREF   #REQUIRED
> min   CDATA   #IMPLIED
> max   CDATA   #IMPLIED
> extrapolate   (neither | min | max | both) #IMPLIED
> interpolationType  CDATA #IMPLIED
> interpolationOrder CDATA #IMPLIED
>>
>
>The justifications for this change are:
>
>For tabulated data in any form, the type of interpolation/extrapolation
>applicable should be dependent on the data, not on the software in use
>to interpret the data.  It is therefore appropriate to include
>interpolation instructions in the XML dataset. 
>
>A variable may be interpolated differently in different functions within
>the same dataset.  Interpolation instructions therefore belong in the
>independentVarRef rather than in the variableDef.  An alternative would
>be to include the interpolation instruction in the bpRef attributes for
>each function, if that was thought preferable.
>
>Examples of the most common entries for these attributes are:
>
>interpolationType="polynomial"
>interpolationOrder="1"
>
>which results in linear interpolation in the relevant degree of freedom,
>with continuity of the function, but not of its derivatives, across the
>breakpoints.  Setting order to "0" allows discrete values, while higher
>order can be chosen if required for rapidly-changing data.
>
>Alternative interpolation types can represent different methods, such as
>"c-spline", or different choice of basis functions, such as "legendre".
>
>In future, it might also be useful to add further options to the
>"extrapolate" attribute to determine whether the extrapolating basis
>function is the same as that used for interpolation.
>
>We await with interest any comments or suggestions.

Dan,

This is a good idea we could easily adopt if there is sufficient interest.

In my experience, almost all real-time simulation facilities use first-order linear 
interpolation (equivalent to your polynomial/1 example) for piloted simulations.

But, this standard is intended to be used by more than just real-time man-in-the-loop 
simulations; my personal interest is for flight control design and stability analysis 
of the same vehicle models. We have often seen a need for smoother interpolations 
(generally cubic splines) to improve the fidelity of the linearized models that are 
extracted to do control design.

I guess my concern is, does this interpolation specification need to be captured with 
the model? It would seem to me that the specific application of the model dictates how 
smooth to make the tabular non-linear data. So, the flight control designer might put 
a smooth curve through every table, while the real-time folks stick with 1st order for 
speed.

However, to show our willingness to accept thoughtful suggestions, I'd be glad to add 
this to the next DTD. Would you prefer the interpolationType to be a closed list:

interpolationType (poly | cspline | legendre) #IMPLIED

or an open-ended CDATA with implementation details spelled out in the reference manual?

Also, a complete spec should (IMHO) give additional details on how to fit a polynomial 
through the data. Just specifying the data and giving the order of the fit does not 
guarantee the same polynomial coefficients will be generated, I don't think, even for 
piece-wise polynomials.  How about Legendre basis functions - what information is 
required to fit these?

We are aware of some efforts to encode an entire non-linear function using a single 
multi-order polynomial, but that's not what you're suggesting, are you?

Let's discuss this further. I think text-based information exchange may rapidly become 
somewhat limiting :)

-- Bruce
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://dcb.larc.nasa.gov/utils/fltsim/DAVE>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

Re: DAVE-ML Scope

[Bruce Jackson]

At 11:56 AM -0500 7/23/04, Jon S Berndt wrote:
>Does DAVE-ML only cover vehicle characteristics, or does it (will it) cover 
>environment and initial conditions?
>
>A question has been raised here in Houston that I found interesting. Say that a 
>simulation application is serving as a prototyping tool for a new flight software 
>capability for some vehicle. I can imagine that both the vehicle characteristics and 
>the control laws could be defined using DAVE-ML. I'm not sure if that is a fair 
>characterization - I can't recall seeing the features of DAVE-ML that address FCS 
>definition. Anyhow, at some point it is possible that the prototyping will be 
>finished and that actual flight software is written - perhaps in a different language 
>than the original prototyping was done in. Subsequently, it might come to pass that 
>the flight software gets to be tested in place of the prototype code. So, then the 
>DAVE-ML definition of the vehicle characteristics would I think need to handle 
>bypassing the prototype FCS capability and instead include the specification of an 
>interface to the actual flight code. Is this a special case, or something that is out 
>of scope for DAVE-ML? Is it already handled?
>
>Jon Berndt

Jon,

DAVE-ML at this point doesn't do control laws; we're limited right now to just static 
models (e.g. aero and inertia models).

In the eventuality that one desires to only use part of a DAVE-ML vehicle spec (as in 
your example, another implementation of flight control laws), the replacement scheme 
is left up to the user. They could eliminate that part of the DAVE-ML model or come up 
with some other means to ignore or switch out portions of the DAVE-ML model.

The scope of DAVE-ML is to specify some baseline flight dynamics model of a vehicle, 
so variations on that theme would have to be handled with either a modified DAVE-ML 
document or some external means.

Not an entirely satisfactory answer, I'm sure; I'll be glad to hear other comments.

-- Bruce Jackson
--
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://dcb.larc.nasa.gov/utils/fltsim/DAVE>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

Eclipse as an editor?

[Bruce Jackson]

Does anyone on this mailing list (sim standards) have any experience with the Eclipse 
integrated development environment (IDE)? It is widely used by the Java community, it 
seems, and is (1) multi-platform, (2) open software and (3) extensible to other 
languages/uses. 

An article in the September 2004 Dr. Dobb's Journal hints that we might be able to 
adapt Eclipse to serve as a DAVE-ML editor.

-- Bruce Jackson
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://dcb.larc.nasa.gov/utils/fltsim/DAVE>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

DAVE-ML web site relocated: daveml.nasa.gov

[Bruce Jackson]

In response to growing interest in using the dynamic aerospace vehicle exchange markup 
language (DAVE-ML), the DAVE-ML home web site has been relocated to

http://daveml.nasa.gov

We invite your comments, as always, on any aspect of the DAVE-ML develoment effort.

DAVE-ML is being jointed developed by members of the American Institute of Aeronautics 
and Astronautics (AIAA) Modeling and Simulation Technical Committee.

-- Bruce Jackson
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://daveml.nasa.gov>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

Re: Variable types

[Bruce Jackson]

>Hi there!
>
>I'm working on a simulator of generic systems.
>The system specification is done in XML and this explains
>my interest in DAVE-ML.
>
>One thing I noticed in DAVE-ML is the lack of a type
>specification (int, bool, float, ...) in the variable definition
>element. Because the system specification can be used to
>generate  code, having an attribute that specifies the type
>is a nice information.
>
>The attribute can be optional, in general it provides more
>information about the variable and it can be used or ignored by
>the application reading the XML.
>
>Similar considerations can be done also to other useful
>variable properties, for instance to explicitely define if
>the variable is a constant, or an input or output variable.
>This information can of course be derived by analisys of the
>use of the variable in the following, but having it (optionally)
>specified is more simple for the code generator, more clear
>for the human reader and allows some checks that can prevent
>errors.
>
>Do you have plans to introduce such kind of attributes in
>future versions of DAVE-ML?
>
>Thanks for your attention and best regards,
>Giovanni A. Cignoni.

Giovanni,

That's an excellent suggestion.

Do you know of an existing set of type specifications that exist in XML-land? Having a 
starting point, or better yet, having a DTD we could appropriate would be nice.

Otherwise, we'll need to come up with a short list (perhaps you've done this above). 
An interesting question would be, do we define the precision (for example, does double 
mean 32-bit or 62-bits?) or is this necessary.

Thanks for the suggestion. Version 1.8b1 will be out soon and probably will address 
this, thanks to your contribution!

-- Bruce
-- 
Bruce Jackson mailto:[EMAIL PROTECTED] Dynamics and Control Branch
18C West Taylor Street MS 132 Airborne Systems Competency
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://daveml.nasa.gov>
Simulation standards discussion listserv mailto:[EMAIL PROTECTED]

Re: Data tables

[Bruce Jackson]

Title: Re: Data tables


At 5:50 PM -0500 9/29/04, Jon S Berndt wrote:
I've been looking at the data table
format for DAVE-ML, for example:

 
 9.5013e-01  6.1543e-01 
5.7891e-02  1.5274e-02  8.3812e-01 1.9343e-01
 2.3114e-01  7.9194e-01 
3.5287e-01  7.4679e-01  1.9640e-02 6.8222e-01
 8.2141e-01  4.1027e-01 
2.7219e-01  2.0265e-01  3.0462e-01 8.5366e-01
 4.4470e-01  8.9365e-01  1.9881e-01  6.7214e-01 
1.8965e-01 5.9356e-01


For JSBSim, we have been working on moving our aircraft config file
format closer to DAVE-ML, where applicable. Our table format is
already similar to the above, though in our case we have the
breakpoints as part of the table data.

As we discuss the newer XML format we intend to use for JSBSim, the
question has been raised about the pros and cons of the above format.
For one, it is nice to be able to look at the data and see what it
means without a bunch of tags obfuscating the data. The above format
also is conducive to import/export with spreadsheet programs. However,
if an editor or automated process is to be used in authoring a DAVE-ML
file (or in our case a JSBSim file) we also ask if there is a greater
benefit in using a more "whole" XML specification, such
as:


   0.1   0.34 

   0.2   0.49 

   0.3   0.57 

   0.4   0.68 

   0.5   1.75
< /tr>


Jon Berndt

Jon,

My goal in the current DAVE-ML table design was to make it as
efficient as an ASCII implementation could be, since these tables
comprise the majority of data in most "heavyweight"
simulations. The interpretation of rows/columns/higher dimensions
comes from the surrounding XML structure in which this table is
embedded; the table doesn't (usually) stand alone.

As you are probably aware, DAVE-ML doesn't embed breakpoints
directly in the tables because these are typically reused - for
example, the angle-of-attack breakpoint set is often used in dozens of
tables. Again, the surrounding XML structure contains a reference to
the appropriate breakpoint set.

I notice the use of HTML row/data delimiters above; those can
easily be achieved for a given table in an XSL transformation
stylesheet so that a browser, for example, can display a DAVE-ML table
properly. We didn't really expect to have to do that, however.

I must confess that Bruce Hildreth has been urging an example of
an "ungridded" table, which the DAVE-ML format supports but
has to date been ignored, sort of like:


   

   0.1, -4.0, 9.5013e-01   
 
 
   

   0.1,  0.0, 6.1543e-01   
 
 
   

   0.5, -4.0, 2.3114e-01   
 
 
   

   0.6,  0.0, 4.1027e-01   
 
 


where you'll notice we embed the independent value(s) in the data
record, ahead of the dependent value.  For this type of data,
there is no breakpoint set per se.  This is more in line with the
"whole" XML implementation you're considering.

I guess you could go hog-wild XML and generate something
like


  
    0.1
    -0.4
    9.5013e-01
 
 

...



but that seems to be overkill to me.

Also note the (optional) use of the modID attribute, so we can
tag each data point to a particular source data document and thus know
where it came from or why it was changed.

[IMPORTANT NOTE TO AIRCRAFT DESIGNERS: do not rely on the table
above to design your aircraft. It is intended for illustrative
purposes only.] :)

-- Bruce

Re: Use of Math-ML with DAVEfunc Version 1.7b1

[Bruce Jackson]

Title: Re: Use of Math-ML with DAVEfunc Version
1.7b1


At 2:04 PM +1000 10/27/04, Keating, Hilary (Contractor)
wrote:
I have been looking at
the example files on the DAVE-ML website (http://daveml.nasa.gov/examples.html), however, have had a problem validating these files
against the DAVEfunc DTD.  This problem seems to have arisen as a
result of the change in the way Math-ML is defined in the
DTD.
 
Currently, the
calculation element is defined as (DAVEfunc version
1.7b1):
 

L2'>
 
 
Previously, it was
defined as (DAVEfunc version 1.5b3 and earlier):
 
http://www.w3.org/TR/MathML2/dtd/mathml2.dtd">
%mathml;

 
 
I am able to validate the
example file, F16_aero.xml against DAVEfunc v1.5b3, however,
when I use DAVEfunc v1.7b1 the element 'mathml2:math' is expected
instead of 'math'.  When I change the 'math' tags to
'mathml2:math' and again try to validate the file against DAVEfunc
v1.7b1, a DTD error is presented saying that the element
'mathml2:math' is undefined.  I am unsure how to link this
element to mathml2.dtd.
 
If anyone is able to
explain how to use Math-ML with the latest version of the DTD, I would
be most grateful.
 

Kind
Regards,
Hilary
Keating

Ms. Keating,

I took out the explicit namespace entity for MathML in version
1.6b1. That  directive inserts the whole mathml2.dtd
document into the DAVE-ML
DTD at that point in the code, which seemed wasteful; I tried to
accomplish the same goal by adding what I thought was the appropriate
default attribute to the  element.

I'm sending you separately a test DTD to see if that fixes
things.
 
What editor or tool are you using to validate?

Thanks,

-- Bruce Jackson
-- 

Bruce Jackson <[EMAIL PROTECTED]>
Guidance and Controls Branch
18C West Taylor Street MS 132  
Research & Technology Directorate
NASA Langley Research
Center  Hampton, Virginia
23681
More info about
DAVE-ML:

Simulation standards discussion listserv
mailto:[EMAIL PROTECTED]

Re: Units of Measure for use in Math-ML datasets

[Bruce Jackson]

Title: Re: Units of Measure for use in Math-ML
datasets


At 12:14 PM +1100 12/17/04, Brian, Geoff wrote:
Hi
all,
 
I noticed
in the DAVE-ML reference that the issue of units-of-measure notation
is still to be finalised.
I have
been looking at this for our flight dynamic / simulation modelling
here in DSTO, and have found that a number of the
proposed
standards have conflicting information for units of measure, both
between standards and within individual
standards.
As a
result, I have prepared a list of units of measure for use with
aircraft modelling here in DSTO (see attached). A
difference
I have
adopted from general conventions is the use of negative powers to
represent divisor units irrespective of whether
the
unit of
measure is metric or imperial (eg. ft s-1 instead of ft/s). I have
found this is simpler when defining something like
ft s-2
instead of ft/s/s or ft/s2.
 
 
I thought that this might be useful as a starting
point for defining a units-of-measure notation for Dave-ML and welcome
any comments.
 
The
references I have used for compiling the list
were:
    "Standards for the Exchange of
Simulation Modeling Data", Preliminary Draft, 9 June 1997, AIAA
Modeling and Simulation Technical Committee.
    "SI Units Dimensional Analysis
&, Chapter 8 Figure -- Conversion Tables", McMahonlines,
MathTech Reference Series.
    http://www.unc.edu/~rowlett/units/index.html
 
hope you
are having an enjoyable lead up to the end of the
year.
Regards
 
Mr Geoff Brian
Aircraft Flight Dynamics and Performance
Engineer.
Air Vehicles Division,
Defence Science and
Technology Organisation.


Brian,

Thanks for the legwork. This may make an excellent starting point
for satisfying the need to standardize units of measure
abbreviations.

I'd like to hear from other interested users on this important
issue. Brian is suggesting writing "ft s-1" instead of
"ft/s" for velocity in English units...

-- Bruce

P.S. Merry Christmas to those that celebrate it (like me).

P.P.S. When does Australia celebrate it (*grin*)? Do you sing
"Sleigh Ride" or "Dreaming of a White Christmas"?
-- bjax
-- 

Bruce Jackson <[EMAIL PROTECTED]>
Guidance and Controls Branch
18C West Taylor Street MS 132  
Research & Technology Directorate
NASA Langley Research
Center  Hampton, Virginia
23681
More info about
DAVE-ML:

Simulation standards discussion listserv
mailto:simstds@larc.nasa.gov

Still alive: simstds@larc.nasa.gov

[Bruce Jackson]

Title: Still alive:
simstds@larc.nasa.gov


SimStds subscribers:

The Simulation Standards mailing list is still alive, as is our
website, .

The lack of traffic has been due, in part, to my other NASA
duties. These will probably continue through the end of August.

However, I wanted to let the list know that Bruce Hildreth and I
will be giving a 90-minute workshop on the proposed DAVE-ML vehicle
dynamic model simulation exchange standard at the AIAA Modeling and
Simulation Technolgies Conference in San Francisco. [The time is
Tuesday, August 16th at 2 PM; the conference is hosted at the Hyatt
Regency in the Embarcadero.] If you're in the area or at the
conference, stop by and say hello!

We continue to seek funding/resources to continue our efforts. I
recently heard from Erik McGuire, a grad student, who is looking at
working on a native DAVE-ML editor based on Qt toolkit. This would be
a nice addition to the limited applications that work with DAVE-ML in
its native state.

If you don't want to get future mailings, see below.

-- Bruce



You are receiving this e-mail because you have been subscribed to
the Simulation Standards mailing list at NASA Langley Research Center.
If you do not wish to receive further mailings, please do the
following (this is NOT a phishing expedition!)

1) prepare an e-mail to "[EMAIL PROTECTED]"
2) put "unsubscribe simstds" in the BODY of the
message
3) Subject line can be blank or anything - it is ignored

If you have questions regarding the simstds@larc.nasa.gov mailing
list, please contact Bruce Jackson, [EMAIL PROTECTED]

-- 

Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems &
Control Branch
8 Langley Boulevard, MS 308
Research & Technology Directorate
NASA Langley Research
Center  Hampton, Virginia
23681
More info about
DAVE-ML:

Simulation standards discussion listserv
mailto:simstds@larc.nasa.gov

Re: DAVEML XML Schema available?

[Bruce Jackson]

Title: Re: DAVEML XML Schema
available?


At 8:49 PM -0600 11/24/05, Jon Berndt wrote:
I visited the DAVEML web page, but did
not seem mention of an XML Schema for DAVEML. I seem to recall some
mention of the existence of a schema. Is there a Schema for DAVEML? I
suspect that there is a way to convert a DTD to a Schema. I'm using
oXygenXML as an editor.

Jon Berndt

Hi, Jon!

We haven't put an XSD (XML Schema Document) together for DAVE-ML
since the jury seems out on wholesale acceptance of XSD's, while DTD's
(Document Type Definitions) seem to be a universally understood schema
description.

The DTD is available from

.

There are translators to convert DTD -> XSD but I don't have
any experience. XSD is a very rich (and some say complex) syntax, so I
don't think there is a conversion the other way.

Internally I use RNC (RelaxNG compressed) schemas to handle the
DocBook-based reference manual and actually to generate the DAVE-ML
DTD + reference sections.  This compact and powerful, but not
universally accepted, schema description comes from James Clark of
thaiopensource.com:



Cheers,

-- Bruce

Re: Table data, XSL, and SVG

[Bruce Jackson]

At 7:04 AM -0600 11/30/05, Jon Berndt wrote:
>I was noticing a gridded table definition (from the example on the DAVEML web 
>site):
>
>
>  
>   
> 
> 
>   
>   
>
> 9.5013e-01   6.1543e-01   5.7891e-02   1.5274e-02   8.3812e-01   1.9343e-01
> 2.3114e-01   7.9194e-01   3.5287e-01   7.4679e-01   1.9640e-02   6.8222e-01
> 6.0684e-01   9.2181e-01   8.1317e-01   4.4510e-01   6.8128e-01   3.0276e-01
> 4.8598e-01   7.3821e-01   9.8613e-03   9.3181e-01   3.7948e-01   5.4167e-01
> 8.9130e-01   1.7627e-01   1.3889e-01   4.6599e-01   8.3180e-01   1.5087e-01
> 7.6210e-01   4.0571e-01   2.0277e-01   4.1865e-01   5.0281e-01   6.9790e-01
> 4.5647e-01   9.3547e-01   1.9872e-01   8.4622e-01   7.0947e-01   3.7837e-01
> 1.8504e-02   9.1690e-01   6.0379e-01   5.2515e-01   4.2889e-01   8.6001e-01
> 8.2141e-01   4.1027e-01   2.7219e-01   2.0265e-01   3.0462e-01   8.5366e-01
> 4.4470e-01   8.9365e-01   1.9881e-01   6.7214e-01   1.8965e-01   5.9356e-01
>   
>  
>
>  
>
>I'm not an XSL transform or XSD schema expert, but I believe the table data 
>will not be
>transformable through XSL, since it is not keyed to specific elements. Is 
>there another
>alternative definition for table data?
>
>The above representation of table data is what I use in the JSBSim table spec. 
>However,
>I've recently been rethinking that. The tabular format above is nice because 
>it can easily
>be edited and is easy on the eyes. However, I'm considering writing an XSL 
>transform that
>would take table data and plot it using SVG. Not sure if that's specifically 
>possible, but
>it would allow for some nice documentation to be produced. It might 
>effectively require
>that an editor for table data should be available for creating flight models, 
>however - if
>that's not already a requirement.
>
>Is there another table data spec format? Has anyone else dealt with using XSL 
>and SVG
>together to plot data contained in a DAVEML flight model?
>
>Jon

Jon,

There is another representation, but it has the same problem: ungridded data 
can be represented using the  element; it gives the 'grid coordinates' 
and function value at those coordinates (the dependent value as a function of n 
independent values) but suffers from the same problem you mention.

I suppose we should discuss an alternative presentation so that XSL can process 
a table into SVG (I've been wanting to look at this, too).

As you point out, we need a table editor application, preferably in Java. See 
the third item on the DAVE-ML to-do list, .

-- Bruce

Re: DAVE-ML Examples

[Bruce Jackson]

At 2:59 PM +0200 6/15/06, Giovanni A. Cignoni wrote:
>Hi,
>
>I'm working on a open source project about code generation for
>simulators of dynamic systems. The project is still very experimental
>but few results are achieved and we are now looking for case studies to 
>challenge our tool. More info are at: http://genesim.sourceforge.net/
>
>We will like to try to translate DAVE-ML in the XML which our code generator 
>is able to process and to verify if translation can
>be automated. Is it possible to have some more examples of DAVE-ML 
>specifications? Maybe something in the middle between the first two very 
>simple examples and the huge F-16 and HL-20 ones.
>
>Thanks in advance and best regards,
>Giovanni A. Cignoni.

Professor Cignoni,

I'm sorry that I don't have many simpler examples - the F-16 is actually a very 
simple model, for a full six-degree-of-freedom aero model. Most of the models I 
deal with, and which DAVE-ML is aimed at, are much more complex than even the 
HL-20 (which is more representative of what we use in our piloted simulations).

The only thing that might be simpler are launch vehicle models; these are 
usually axi-symmetric and thus have lower degrees of freedom. Unfortunately, 
they're regarded as 'munitions' and I can't share them.

Sorry to not be of much help, but I'm delighted to hear of your efforts. I'll 
visit the genesim website for more information about your project.

-- Bruce Jackson
-- 
Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems & Control Branch
8 Langley Boulevard, MS 308 Research & Technology Directorate
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://daveml.nasa.gov>
Simulation standards discussion listserv mailto:simstds@larc.nasa.gov

Re: Suggestion for Aero-ML

[Bruce Jackson]

At 9:29 PM -0500 9/22/06, Jon S. Berndt wrote:

I believe it would be desirable to have a text field in AERO-ML to specify a
license for the file, and also to have a field for specifying the
sensitivity (secret, classified, proprietary, etc.).

I suppose that the license field could look like this:



-or-


  For more information, see www.gnu.org/gpl


I expect that the sensitivity field would simply be something like:



-or-


  This file should only be distributed in accordance with company policy
THX1138.


Comments?

Jon Berndt



Would there be merit to having an optional subelement to sensitivity, 
such as classification?  This would allow, if sensitivity was 
'classified' to indicate the level of classification (confidential, 
secret, top secret) (at least in the US, that's how this works).


-- Bruce

Re: The use of Provenance

[Bruce Jackson]

At 10:13 AM +1000 9/22/06, Brian, Geoff wrote:
Hi all,

We have been having some discussion here about the use of the 
Provenance definition for detailing the source of data used to build 
data sets.


Currently Provenance provides information on the author, function 
creation data, and links to reference and modification definitions. 
We have been pondering what is the best technique for detailing where 
in a reference data may be sourced from (the page/paragraph/figure or 
table of reference documents). One consideration was to include this 
information as a standard XML comment; however, the information would 
then only be available to someone visually reading the dataset file. 
Another consideration was to at add content attribute tags to 
Provenance to allow , , number> and < table number>, etc to be defined explicitly, although 
this adds many attribute tags over complicates the provenance 
definition. The other option discussed was to included a description 
attribute to store the additional information.


The Provenance definition is only associated with tabular data and 
function tables. We were also thinking that it would be useful to 
associated provenance (optionally) with variableDefs and check data. 
We commonly use VariableDefs  to store constants (wing area, span 
etc) as well as being used for MathML expressions. We can store the 
information on the data source in the description attribute, but 
would prefer to use a technique like the provenance definition as it 
would provide a consistent way of defining source information for all 
data/equations included in a dataset.


I am keen to here others ideas?

Regards
Geoff Brian


Geoff,

I'm at a loss as to how to best proceed. We could make provenance or 
provenanceRef a sub-element of varDef; this would let you write the 
provenance in the file header and then cite it wherever necesssary.


Regarding the need to cite page, number and verse, we should perhaps 
flesh out the reference element to include more complete citation 
information. Since a provenance points to a reference, would this 
suffice?


-- Bruce

RE: Variable name convention for units

[Bruce Jackson]

At 3:57 PM +1000 9/26/06, Brian, Geoff wrote:

Hi all,

I have struggled with the recommended variable naming standard for a
while due to its implications on writing clean code.

My conclusion was that when writing code I would probably not use the
name as recommended. I would include a reference to the axis systems but
remove the units. For example: airpathBankAngle- for the bank angle
relative to the airpath.
flightpathBankAngle - for the bank angle relative to
the flightpath.
geographicX - the X position in geographic
coordinates.
geodeticY   = the Y position in geodetic
coordinates.
velocityBodyEarth_Geographic - the velocity vector
of the aircraft CG (Body) with respect to the Earth, expressed in
Geographic coordinates.
Etc.

The reasoning behind this is to minimise coding effort by making the
code to be as general as possible, and therefore reusable irrespective
of the computing unit basis (Imperial, metric, etc). Variables would be
scaled to a common computing unit basis using a unit identifier, such as
that stored in "units=" attribute in Aero-ML files before being used.
The unit identifier e.g. fs-1, etc are easily treated as character
strings and thus not an arithmetic operation.

If the purpose of the naming standard is to associate a name with data,
as done in Aero-ML files, it can easily be accommodated by treating it
as a character string. If the purpose is to define the recommended
naming convention for variables within a piece of code, I would suggest
a rethink maybe similar to that above.

My interpretation of the naming standard was to use it to name data
within the Aero_ML files, and therefore, I don't really see the problem
associated with using a "-" within the unit definition, be it in the
name or units tag.

I think I mentioned this already, but if not I think it useful to have a
separator character between unit types (e.g. a '.', '_' or space:
ft.s-1 or ft_s-1, or ft s-1). This would improve readability of the
units associated with a variable and avoid confusion where a symbol may
be both a prefix and a unit definition (e.g. 'd' a as degrees or as a
prefix of deci). It would also simplify to process of parsing a unit
character string within a program that computes unit conversions.

Finally,
The following also has definitions for axes conventions that may be of
worth considering;
ISO 1151 (version current for each part at 30 June 2004), Flight
Dynamics - Concepts, Quantities
and Symbols, International Organization for Standardization.

Regards
Geoff Brian
Aircraft Performance and Flight Dynamics
Defence Science and Technology Organisation



and at 1:09 PM -0400 9/25/06, Hildreth, Bruce wrote:

How about changing the "-" to a "_"?


So
s_bodyXVelocity_fs-1

Would be
s_bodyXVelocity_fs_1


I am agreement now with Brian, in contrast with a previous 
correspondence with Bruce Hildreth.


If all modeling is done in XML, the units are 'meta-data' that is 
carried in the variable definition as an attribute, and *could* 
include "ft_s-1" as an encoding method to describe actual units.


This is now my preferred solution. Alternatively, we could adopt both 
(meta info and underscore).


Carrying the units with the variable name means at least two 
different variables to track alpha, beta, etc. in SI and English 
units...


-- Bruce

New version of DAVEfunc DTD

[Bruce Jackson]

I have just uploaded a new version of the DAVEfunc DTD to the DAVE-ML 
website, version 1.9b2, which addresses several suggested 
improvements and fixes a bug or two.


<http://daveml.larc.nasa.gov/DTDs.html>

The complete list of changes is found in the updated reference 
manual, either in PDF or HTML format, but the major items are:


Added an enumeration attribute to the independentVar elements to 
indicate that the function should be interpolated with a quartic 
spline
Added a reference to a most useful Wikipedia page that describes 
spline interpolation in detail

Corrected a missing ENTITY element that now properly includes the MathML2 DTD
Added two ungridded table examples to the reference manual

Most of these changes came from suggestions from Geoff Brian of 
Australia's DSTO; that agency has embraced DAVE-ML and is now 
providing a C++ API library, Janus, available under Open Source 
license


<http://www.dsto.defence.gov.au/research/4675>

The manual also contains two new examples; these are a result of the 
AIAA's review of DAVE-ML as a proposed standard for simulation model 
exchange.


I was actually working on the final checkout of the new DTD when the 
message from Dr. Cignoni was posted; that was a pleasing serendipity 
because this revised DTD will address most if not all of the bugs he 
and his GeneSim project team found.


 <http://genesim.sourceforge.net>

Thanks for the helpful suggestions!

-- Bruce Jackson
--
Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems & Control Branch
8 Langley Boulevard, MS 308 Research & Technology Directorate
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://daveml.nasa.gov>
Simulation standards discussion listserv mailto:simstds@larc.nasa.gov

Re: Calculation order

[Bruce Jackson]

At 7:34 PM +0100 11/24/06, Giovanni A. Cignoni wrote:

Hi there,

thank for the new versions of the files.

Now we are facing another problem regarding the order of definitions
and uses of variables. The reference manual of DAVE-ML states that
"variableDefs should appear in calculation order" (page 9 of v. 1.9b2).

That "should" is a requirement or just a good practice suggestion?

In the F16 dml there are two cases of variables used before they are
defined (details by G. Mirri are in the following).

I suppose that, at this point in the development of DAVE-ML, the true
requirement is that definitions and uses may appear not in order, but an
ordering must be possible:
- writing them in order is just a good practice for the readability of
  the XML;
- if an ordering is not possible (there is a cycle) the DAVE-ML is not
  valid.

Is this right?

Thanks in advance,
Giovanni A. Cignoni.


---

F16_aero.dml Revision: 108

 - line 372: definition of variable "cl1" refers to variable "clt" in
   the calculation block (at line 379), but variable "clt" is not yet defined
   (it will be defined later at line 488);

 - line 395: definition of variable "cn1" refers to variable "cnt" in
   the calculation block (at line 402), but variable "cnt" is not yet defined
   (it will be defined later at line 519).



Giovanni,

Thanks again for finding and report this mistake.

It would appear, then, that variableDef order is NOT important, but I 
still think it is a good idea. As Dan Newman pointed out in his 
reply, problems may occur with some processors if functions are 
defined out-of-order.


Your two suggestions are probably exactly right.  It IS good practice 
(IMHO) to define the variables in the order they will be used; if 
this is not possible, we could end up with a circular reference which 
would (for a static model) indicate a problem.


I will fix the F16 model and reword the reference guide.

Thanks again for finding these bugs!

-- Bruce Jackson
--
Bruce Jackson <[EMAIL PROTECTED]>  or  http://public.xdi.org/=bjax
Dynamic Systems & Control BranchResearch & Technology Directorate
8 Langley Boulevard, MS 308
NASA Langley Research Center  Building 1232, Room 316
Hampton, VA 23681-0001 scud://N 37 05'31.7" W 76 22'55.1"
http://dcb.larc.nasa.gov/DCBStaff/ebj/ebj.html  "There is no try"

Re: Calculation order

[Bruce Jackson]

At 7:34 PM +0100 11/24/06, Giovanni A. Cignoni wrote:

Hi there,

thank for the new versions of the files.

Now we are facing another problem regarding the order of definitions
and uses of variables. The reference manual of DAVE-ML states that
"variableDefs should appear in calculation order" (page 9 of v. 1.9b2).

That "should" is a requirement or just a good practice suggestion?

In the F16 dml there are two cases of variables used before they are
defined (details by G. Mirri are in the following).

I suppose that, at this point in the development of DAVE-ML, the true
requirement is that definitions and uses may appear not in order, but an
ordering must be possible:
- writing them in order is just a good practice for the readability of
  the XML;
- if an ordering is not possible (there is a cycle) the DAVE-ML is not
  valid.

Is this right?

Thanks in advance,
Giovanni A. Cignoni.



Dr. Cignoni,

I have posted an updated F-16 subsonic aerodynamics example model on 
the DAVE-ML website


  <http://daveml.nasa.gov/examples.html>

that has the variableDefs sorted correctly.

I will be amplifying the paragraph on variableDefs in the next 
version of the reference manual


  <http://daveml.nasa.gov/DTDs.html>

to read:

The variableDefs should appear in calculation order; that is, a 
variableDef should not appear before the definitions of variables 
upon which it is dependent. This is good practice since doing so 
avoids a circular reference. If a variable depends upon the output 
(dependentVar) of a function it can be assumed that dependence has 
been met, since functions are defined later in the DAVEfunc element.


Thanks for the excellent feedback, and I'm sorry to not have caught 
this obvious poor example.


-- Bruce Jackson
--
Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems & Control Branch
8 Langley Boulevard, MS 308 Research & Technology Directorate
NASA Langley Research Center  Hampton, Virginia 23681
More info about DAVE-ML: <http://daveml.nasa.gov>
Simulation standards discussion listserv mailto:simstds@larc.nasa.gov

Re: F16 check data.

[Bruce Jackson]

At 1:48 PM +0100 3/9/07, Giovanni A. Cignoni wrote:

Hi,

we are still working at the translation of Dave-ML files in our
system specification XML format, from which we can generate code
(see http://genesim.sourceforge.net/).

We are now testing the results running the code we generate.

It is possible to have data to check that model output is correct?
In the HL20 examples there are check data blocks, but there are not
in the F16 one, which, being little, is more usable for first tests.
In the F16 references there is some Mathlab code, but it calls few 
external functions.


Of course, if someone has DAVE-ML models (with check data) that is 
possible to share, we will be happy to test our tool on them.


Thanks in advance, Giovanni A. Cignoni.


Giovanni,

The F-16 subsonic aero example model,

http://daveml.nasa.gov/examples/F16_aero.dml

has 17 difference checkcases (staticshot) blocks.

Are you looking at an earlier version?

-- Bruce Jackson

DAVEtools 0.8 now released as Open Source

[Bruce Jackson]

A software tool for manipulating and converting aerodynamic models in the
Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML) format has been
approved for release as NASA Open Source software.

DAVE-ML, a grammar based on the standard Extensible Markup Language (XML),
provides a single data source file for aerodynamic models used in flight
simulations and dynamic analysis tools and codes. The grammar captures not
only the data tables as in a traditional aero model source file but also
encodes the algebraic build-up equations, provenance or history of the
model, tracking of changes on a point-by-point basis, uncertainty, and
verification checkcase data, all in a human- and machine-readable text
format.

Adoption of this format can save substantial amounts of human effort in
rehosting simulation models originating from other sources such as industry
partners. It is being evaluated by the AIAA as part of a proposed standard
format for flight simulation models.

DAVEtools, the newly released software product, is a Java-based utility
package that allows verification, interactive evaluation, and translation of
a DAVE-ML aero model into the proprietary Matlab/Simulink model format, a
popular analysis engine. From Simulink, the model can be converted into C
source code along with verification scripts.

DAVEtools is intended to be expanded to export from DAVE-ML into other
formats including directly into C, C++ or FORTRAN source code.

Designation as NASA Open Source allows direct download from NASA web servers
without requiring an executed license agreement and encourages collaborative
improvements to the code.

DAVEtools is available from the Dynamic Systems and Control Branch website,
http://dscb.larc.nasa.gov/Products/index.html.

More information about DAVE-ML in general is available at
http://daveml.nasa.gov

-- Bruce

-- 
Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems & Control Branch
8 Langley Boulevard, MS 308 Research & Technology Directorate
NASA Langley Research Center  Hampton, Virginia 23681
"Have a better life with flight simulation model standards:  DAVE-ML"
Help develop portable simulations:   <http://daveml.nasa.gov>

New version of DAVEfunc DTD 1.9b3

[Bruce Jackson]

I have just uploaded a new version of the DAVEfunc DTD to the DAVE-ML  
website, version 1.9b3, which adds a DSTO-suggested improvement. In  
addition to the DTD, the reference manual has an example of how to  
invoke the 'atan2' function and fixes documentation links.


   <http://daveml.larc.nasa.gov/DTDs.html>

The main change to the DTD is addition of 'discrete' as a supported  
interpolation method for tabular data, yielding a stair-step response  
from such a function. This came from a suggestion from Geoff Brian of  
Australia's DSTO.


The manual also contains an example of how to encode the 'atan2' four- 
quadrant arctangent function, which is not directly supported in  
MathML2 grammar.


-- Bruce


Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems & Control Branch
8 Langley Boulevard, MS 308   Research & Technology Directorate
NASA Langley Research CenterHampton, Virginia 23681
More info about DAVE-ML:   <http://daveml.nasa.gov>
Simulation standards discussion listserv <mailto:simstds@larc.nasa.gov>

Re: Discrete interpolation attribute (was New version of DAVEfunc DTD 1.9b3)

[Bruce Jackson]

On Jun 18, 2007, at 1:28 PM, Giovanni A. Cignoni wrote:

The main change to the DTD is addition of 'discrete' as a  
supported  interpolation method for tabular data, yielding a stair- 
step response  from such a function. This came from a suggestion  
from Geoff Brian of  Australia's DSTO.


"Discrete" interpolation is the method also known as "nearest  
neighbor"?
Being x in [a, b], f(x) is f(a) or f(b) depending on x being nearer  
to a or b. Correct?


Thanks in advance, ciao,
Giovanni Cignoni.



This is a good question, Giovanni. I see that we need to be much more  
rigorous in our definition of 'discrete' as it applies to these tables.


I had assumed the interpretation would be as follows (I don't think  
this is 'nearest-neighbor')...


In the case of a one-dimensional function, if the independentVarPts  
are defined as


 [a, b, c, d]

and an arbitrary griddedTable points are defined as

 [8.5, 9.0, 9.5, 10.0]

the function f(x) would be evaluated as shown below:

f(x)   ^
   |
10.0 - |o
   ||
   ||
 9.5 - | o--o
   | |
   | |
 9.0 - |  o--o
   |  |
   |  |
 8.5 - |   o--o
   |
   |--> X
   |  |  |  |
   a  b  c  d

so the independent values state where the function changes value.

Nearest-neighbor would put the transitions exactly between the  
independent break points.


I'd appreciate any feedback on this topic, especially from Geoff  
Brian who is apparently making use of this 'extension' to DAVE-ML.


-- Bruce

Re: Discrete interpolation attribute

[Bruce Jackson]

On Jun 19, 2007, at 5:33 PM, Brian, Geoff wrote:


From: Bruce Jackson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 19 June 2007 3:40 AM
To: Giovanni A. Cignoni
Cc: simstds@larc.nasa.gov
Subject: Re: Discrete interpolation attribute (was New version of
DAVEfunc DTD 1.9b3)


On Jun 18, 2007, at 1:28 PM, Giovanni A. Cignoni wrote:


The main change to the DTD is addition of 'discrete' as a supported
interpolation method for tabular data, yielding a stair- step
response  from such a function. This came from a suggestion from
Geoff Brian of  Australia's DSTO.


"Discrete" interpolation is the method also known as "nearest
neighbor"?
Being x in [a, b], f(x) is f(a) or f(b) depending on x being  
nearer to



a or b. Correct?

Thanks in advance, ciao,
Giovanni Cignoni.



This is a good question, Giovanni. I see that we need to be much more
rigorous in our definition of 'discrete' as it applies to these  
tables.


I had assumed the interpretation would be as follows (I don't  
think this

is 'nearest-neighbor')...

In the case of a one-dimensional function, if the  
independentVarPts are

defined as

  [a, b, c, d]

and an arbitrary griddedTable points are defined as

  [8.5, 9.0, 9.5, 10.0]

the function f(x) would be evaluated as shown below:

f(x)   ^
|
10.0 - |o
||
||
  9.5 - | o--o
| |
| |
  9.0 - |  o--o
|  |
|  |
  8.5 - |   o--o
|
|--> X
|  |  |  |
a  b  c  d

so the independent values state where the function changes value.

Nearest-neighbor would put the transitions exactly between the
independent break points.

I'd appreciate any feedback on this topic, especially from Geoff  
Brian

who is apparently making use of this 'extension' to DAVE-ML.

-- Bruce


I also agree that this is a good question. There are times when
interrogating data where it is necessary to return either a truncated
value, as you describe Bruce, or the nearest neighbour. Thus a single
'discrete' attribute may not have been the best suggestion. This is
something we had overlooked in suggesting such an attribute. At the  
risk

of fattening the dtd with unnecessary options, having attributes for
both these cases would be useful.

At present, the data tables I am currently using the 'discrete'
attribute for are more akin to nearest-neighbour.

Regards
Geoff


So now I'm considering the following, and would appreciate any  
feedback from the community:


Instead of a single 'discrete' attribute, provide for three:

'nearest' which performs as Geoff described above (not how my diagram  
is drawn)
'floor' which holds the previous dependent value until the next  
breakpoint is reached (which matches my diagram above)
'ceiling' which rounds up the next dependent value upon passing each  
breakpoint.


This seems to be the most flexible, but perhaps also the most complex  
and may not be worth the effort.


What say the combined intelligence of artisans?

-- Bruce

New version of DAVEfunc DTD: version 2.0 (release candidate 1)

[Bruce Jackson]

I have uploaded a new version of the DAVEfunc DTD to the DAVE-ML  
website, version 2.0 Release Candidate 1, which was cleaned up  
somewhat for submission to the AIAA Committee on Standards. It  
includes new 'ceiling' and 'floor' interpolation attributes and  
several uncertainty examples.


   <http://daveml.larc.nasa.gov/DTDs.html>

Comments welcomed, but at this point the changes probably will go  
through a committee instead of just me.


-- Bruce


Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems & Control Branch
8 Langley Boulevard, MS 308   Research & Technology Directorate
NASA Langley Research CenterHampton, Virginia 23681
More info about DAVE-ML:   <http://daveml.nasa.gov>
Simulation standards discussion listserv <mailto:simstds@larc.nasa.gov>

Re: Edits for DAVE-ML Reference Manual Version 2.0RC1 Rev 273.

[Bruce Jackson]

Thanks, Dennis,

It's great to have a fresh pair of eyes look at something like this;  
I appreciate the comments.


Look for these fixes in RC2.

-- Bruce

On Oct 31, 2007, at 11:22 AM, Linse, Dennis J. wrote:



Bruce,

I was just reading through the latest DAVE-ML manual (Dynamic  
Aerospace

Vehicle Exchange Markup Language (DAVE-ML) Reference, Version 2.0RC1,
$Revision: 273 $) and noticed that in the following sections:

Gridded table definition (page 22)
Ungridded table definition (page 25)
Function definition (page 30)

provenance is mentioned as an optional sub-element, but  
provenanceRef is
not mentioned at all, although it is a valid option.  They are  
correctly

documented in Appendix A.

Along the same line, neither provenance nor provenanceRef is mentioned
in the variable definition section (page 15) or the checkData section
(page 35).  A nit-pick would be that on page 35, the only true
sub-element to checkData is staticShot.  checkInputs, internalValues,
and checkOutputs are sub-elements of staticShot.


Hope this is helpful.

Dennis
---
Dennis J. Linse, Aerospace Engineer
Science Applications International Corporation
+1-703-294-4449  

Re: Matrix and Vector definitions for DaveML

[Bruce Jackson]

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:


  dimensions="3">

2
6
3
My Data Matrix is a 2x6x3 matrix; the last  
dimension changes most rapidly


   111 112 113  

   121 122 123
   131 132 133
   141 142 143
   151 152 153
   161 162 163
   

   211 212 213 221 222 223 231 232 233 241 242 243 251 252
 253 261   262   263  


  

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):
dim1="4">


For a 2-D matrix of size (4x6):
dim1="4" dim2="6">


For a n-D matrix of size (4x6x3x...):
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.

Re: arrayDef & draft simstd comments

[Bruce Jackson]

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  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  elements, in the
same way that a gridded table's dimensional size is specified by the
number of  (and also ) elements.

I'd keep  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  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 PROTEC

Re: namespaces and MathML

[Bruce Jackson]

On Mar 17, 2008, at 9:34 PM, Dan Newman wrote:

I've been looking over the DTD version 2.0 Release Candidate 1,  
applying it to validation of a dataset.


To do this I've been using emacs nxml-mode, which requires pre- 
translation of the DTD to a RELAX-NG schema format.  The translation  
is performed automatically, but the change in format made a quirk in  
the DTD mor obvious.  DAVEfunc.dtd does not set a default namespace,  
but the included MathML2 DTD does.  This can have the effect of  
competing namespaces, which will confuse some validating parsers.   
It has absolutely no effect on any application of the DTD to data  
handling.


However, to avoid the problem entirely, I'd like to suggest that  
DAVEfunc should be given a default, blank (or otherwise if you like)  
namespace, and that this should be allocated before the mathml2  
entity is declared.  I have attached a version of the DTD with this  
change included.  Please consider it.


--
Regards,
Dan Newman


Thanks, Dan;

I too use emacs with nxml-mode and have long wondered how to resolve  
this issue; I had about given up on getting at the root of the  
problem. Thanks for figuring it out!


It may well be time to give DAVEfunc a namespace to avoid collisions.  
I'm working on release candidate 2 and we may want to add a namespace  
such as dml.


-- Bruce

Simstds mailing list preparing to move

[Bruce Jackson]

The mailing list to which this address is subscribed, 'simstds@larc.nasa.gov 
', is transitioning to a new NASA-wide list, 'sim- 
[EMAIL PROTECTED]'. Please note the change in name as well as host.


This is due to a consolidation within NASA to centralize services  
(including mailing lists) across the agency.


You will receive an invitation to join the new list; you should be  
able to join by simply replying to that invitation.


If you do not wish to remain in the discussion, feel free to delete  
the message.


It is not yet clear how long the Langley list server will remain  
active, but please begin to address discussion topics to the new  
address once you've successfully subscribed. I will attempt to have  
the messages cross-posted to both lists, so you may wish to  
unsubscribe from the old list.


To join the new list, either reply to the invitation or send a blank  
email to [EMAIL PROTECTED], or visit the information  
page, https://lists.nasa.gov/mailman/listinfo/sim-stds


To unsubscribe from the old list, send an email message from the  
subscribed address to [EMAIL PROTECTED], with 'unsubscribe  
simstds' in the BODY of the message (don't include the quotation  
marks, either).


For more information about this list, as well as a way to retrieve  
your password to make personal account changes, visit the information  
page:


https://lists.nasa.gov/mailman/listinfo/sim-stds

Sorry for the inconvenience.

-- Bruce Jackson




Bruce Jackson <[EMAIL PROTECTED]> Dynamic Systems & Control Branch
8 Langley Boulevard, MS 308   Research & Technology Directorate
NASA Langley Research CenterHampton, Virginia 23681
More info about DAVE-ML:   <http://daveml.nasa.gov>
Simulation standards discussion list   <mailto:[EMAIL PROTECTED]>