Shown below are schematic overviews of the various elements currently available in DAVEfunc. Each element is described in detail in the appendix. The following key is used to describe the elements and associated attributes.
Key:
elementname : mandatory_attributes, [optional_attributes]
mandatory_single_sub-element
optional_single_sub-element?
[ choice_one_sub-element | choice_two_sub-element ]
zero_or_more_sub-elements*
one_or_more_sub-elements+
(character data) implies Unicode text information
The DAVEfunc element has six possible sub-elements:
DAVEfunc :
fileHeader
variableDef+
breakpointDef*
griddedTableDef*
ungriddedTableDef*
function*
DAVEfunc sub-elements:
- fileHeader
This mandatory element contains information about the origin and development of this model.
- variableDef
Each DAVEfunc model must contain at least one signal path (such as a constant output value). Each signal used within the model must be specified in a separate variableDef.
A signal can have only a single origin (an input block, a calculation, or a function output) but can be used (referenced) more than once as an input to one or more functions, signal calculations, and/or as a model output.
- breakpointDef
A DAVEfunc model can contain zero, one or more breakpoint set definitions. These definitions can be shared among several gridded function tables.
- griddedTableDef
A DAVEfunc model can contain zero, one, or more gridded nonlinear function table definitions. Each table must be used by at least one but can be used by more than one function definition if necessary for efficiency. Or some or all functions in a model can specify their tables internally with an embedded griddedTableDef element or ungriddedTableDefwithout sharing any table definitions.
A gridded function table contains dependent values, or data points, corresponding to the value of a function at the intersection of one or more breakpoint sets (one for each dimension of the table). The independent values (coordinates) are not stored within the gridded table definition but are referenced by the parent function. This allows a function to be shared by more than one set of breakpoint values (such as left and right aileron deflections).
The associated function element that references a gridded table associates the dimensions of the table with both the correct breakpoint (independent coordinate) set and the corresponding independent variable or input signal for each dimension.
The table data point values are specified as comma-separated values in floating-point notation (0.93638E-06) in a single long sequence as if the table had been unraveled with the last-specified dimension changing most rapidly. Line breaks are to be ignored. Comments may be embedded in the table to promote [human] readability.
- ungriddedTableDef
A DAVEfunc model can contain zero, one, or more ungridded nonlinear function table definitions. Unlike a rectangularly-gridded table, an ungridded table specifies data points as individual sets of independent and dependent values. Each table must be used by at least one but can be used by more than one function definition if necessary for efficiency. Or all functions can retain their tables internally with a ungriddedTable element without sharing the table values with other functions.
Ungridded table values are specified as a single (unsorted) list of independent variable (input) values and associated dependent variable (output) values. While the list is not sorted, the order of the independent variable values is important and must match the order given in the using function. Thus, functions that share an ungridded table must have the same ordering of independent variables.
The method of interpolating the ungridded data is not specified.
- function
A function ties together breakpoint sets (for gridded-table nonlinear functions), function values (either internally or by reference to table definitions), and the input- and output-variable signal definitions. Functions also include provenance, or background history, of the function data such as wind tunnel test or other source information.
Each of these sub-elements is described further in this reference, and in detail in appendix A.
The fileHeader element contains information about the source of the data contained within the DAVEfunc major element, including the author, creation date, description, reference information, and a modification history.
fileHeader : [name]
author : name, org, [xns, email]
address? :
(address character data)
fileCreationDate : date
fileVersion? :
(version identification character data)
description? :
(description character data)
reference* : refID, author, title, date, [accession, href]
modificationRecord* : modID, [refID]
author : name, org, [xns, email]
address? :
(address character data)
description? :
(descriptive character data)
extraDocRef? : refID
fileHeader sub-elements:
- author
Name, organization, and optional XNS ID and mailing address of the author
- fileCreationDate
Creation date of this file. See the "Additional DAVE-ML conventions" section later in this document for the recommended format.
- fileVersion
A string that indicates the version of the document. No convention is reached, but this could include an automated revision number from configuration control processes.
- description
Optional but recommended text description: what does this DAVE-ML file represent?
- reference
A list of zero or more references with a document-unique ID (must begin with alpha character), author, title, date, and optional accession and URL of the reference.
- modificationRecord
An optional list of modifications with optional reference pointers, as well as author information and descriptions for each modification record. These modifications are referred to by individual function tables and/or data points, using the AIAA modification letter convention. If more than one document is associated with the modification, multiple sub-element extraDocRefs may be used in place of the modificationRecord 's refID attribute.
Example�1.�An example of a fileHeader element
<!-- ================= --><!-- ========================= FILE HEADER ========================= --> <!-- ================= --> <fileHeader>
<author name="Bruce Jackson" org="NASA Langley Research Center" xns="@bjax" email="[email protected]"> <address>MS 132 NASA, Hampton, VA 23681</address> </author> <fileCreationDate date="2003-03-18"/>
<fileVersion>$ Revision: 1.24 $</fileVersion>
<description> Version 2.0 aero model for HL-20 lifting body, as described in TM-107580. This aero model was used for HL-20 approach and landing studies at NASA Langley Research Center during 1989-1995 and for a follow-on study at NASA Johnson Space Center in 1994 and NASA Ames Research Center in 2001. This DAVE-ML version created 2003 by Bruce Jackson to demonstrate DAVE-ML. </description> <reference refID="REF01"
author="Jackson, E. Bruce; Cruz, Christopher I. & and Ragsdale, W. A." title="Real-Time Simulation Model of the HL-20 Lifting Body" accession="NASA TM-107580" date="1992-07-01" /> <reference refID="REF02" author="Cleveland, William B. <[email protected]>" title="Possible Typo in HL20_aero.xml" accession="email" date="2003-08-19" /> <modificationRecord modID="A" refID="REF02">
<author name="Bruce Jackson" org="NASA Langley Research Center" xns="@bjax" email="[email protected]"> <address>MS 132 NASA, Hampton, VA 23681</address> </author> <description> Revision 1.24: Fixed typo in CLRUD0 function description which gave dependent signal name as "CLRUD1." Bill Cleveland of NASA Ames caught this in his xml2ftp script. Also made use of 1.5b2 fileHeader fields and changed date formats to comply with convention. </description> </modificationRecord> </fileHeader>
| | Use of comments makes these big files more readable by humans. |
| | Start of fileHeader element. |
| | See the note regarding date format convention below. |
| | In this example, the revision number is automatically inserted by CVS or RCS, an automated versioning system. |
| | All documents referenced by notation throughout the file should be described here, in reference elements. |
| | All modifications made to the contents of this file should be given here for easy reference in separate modificationRecord elements. |