6.2.7. The checkData element

Prev		Next

The checkData element contains one or more input/output vector pairs (and optionally a dump of internal values) for the encoded model to assist in verification and debugging of the implementation.

    checkData
      staticShot+ : name, [refID]
            description?
                {text description of the static test case}
                    (provenance | provenanceRef)?   {as defined previously}
            checkInputs
                signal+
                    signalName
                    signalUnits
                    signalValue
            internalValues?
                signal+
                    varID 
                    signalValue
            checkOutputs
                signal+
                    signalName
                    signalUnits
                    signalValue
                    tol

checkData sub-elements:

staticShot: One or more check-case data sets, each of which contain mandatory sub-elements checkInputs and checkOutputs vectors (with required match tolerances), and optional provenance, provenanceRef, description and internalValues sub-elements.

Example 14. Check-case data set excerpt

A DAVE-ML file excerpt specifying a check-case data set example for a simple model

  <checkData>
    <staticShot name="Nominal" refID="NOTE1"> 
      <description>An example static check of a simple DAVE-ML model</description>
      <checkInputs>  
        <signal>  
          <signalName>trueAirspeed</signalName>
          <signalUnits>f_s</signalUnits>
          <signalValue> 300.000</signalValue>
        </signal>
        <signal> 
          <signalName>angleOfAttack</signalName>
          <signalUnits>deg</signalUnits>
          <signalValue>   5.000</signalValue>
        </signal>
         .
         .       (similar input signals omitted)
         .
        <signal>
          <signalName>delta elevator</signalName> 
          <signalUnits>deg</signalUnits>
          <signalValue>   0.000</signalValue>
        </signal>
      </checkInputs>
      <checkOutputs> 
        <signal>  
          <signalName>CX</signalName>
          <signalUnits>nd</signalUnits>
          <signalValue>-0.00400000000000</signalValue>
          <tol>0.000001</tol>
        </signal>
         .
         .       (similar output signals omitted)
         .
      </checkOutputs>
    </staticShot>
    <staticShot name="Positive pitch rate"> 
      <checkInputs> 
         .
         .       (similar input and output signal information omitted)
         .
      </checkOutputs>
    </staticShot>
    <staticShot name="Positive elevator">
      <checkInputs> 
         .
         .       (similar input and output signal information omitted)
         .
      </checkOutputs>
    </staticShot>
  </checkData>

	This first check-case refers to a note given in the file header; this is useful to document the source of the check-case values.
	The `checkInputs` element defines the input variable values, by variable name, as well as units (so they can be verified).
	Multiple `signal` elements are usually given; taken together, these scalar `signals`s represent the check-case input "vector."
	The `checkOutputs` element defines output variable values that should result from the specified input values.
	Note the included tolerance value, indicating the absolute value tolerance within which the output values must match the check-case data values.
	Multiple check-cases may be specified; this one differs from the previous check-case due to an increase in the pitching-rate input.

Example 15. A second checkData example with internal values

This example shows another check-case; this one includes intermediate values as an aide to debugging a new implementation.

  <checkData>
    <( provenance | provenanceRef )?>
    <staticShot name="Skewed inputs">
      <description>
        Another example static check; this one includes all the internal, intermediate calculations
        to assist in debugging the implementation.
      </description>
      <checkInputs> 
        <signal> 
          <signalName>trueAirspeed</signalName>
          <signalUnits>f_s</signalUnits>\
          <signalValue> 300.000</signalValue>
        </signal>
        <signal>
          <signalName>angleOfAttack</signalName>
          <signalUnits>deg</signalUnits>
          <signalValue>  16.200</signalValue>
        </signal>
         .
         .       (similar input values omitted)
         .
        <signal>
          <signalName>bodyPositionOfCmWrtMrc</signalName>
          <signalUnits>fracMAC</signalUnits>
          <signalValue>   0.123</signalValue>
        </signal>
      </checkInputs>
      <internalValues> 
        <signal>
          <varID>vt</varID>
          <signalValue>300.0</signalValue>
        </signal>
        <signal>
          <varID>alpha</varID>
          <signalValue>16.2</signalValue>
        </signal>
         .
         .       (similar internal values omitted)
         .
      </internalValues>
      <checkOutputs>
        <signal>
          <signalName>aeroBodyForceCoefficient_X</signalName>
          <signalValue> 0.04794994533333</signalValue>
          <signalUnits>nd</signalUnits>
          <tol>0.000001</tol>
        </signal>
        <signal>
          <signalName>aeroBodyForceCoefficient_Z</signalName>
          <signalValue>-0.72934852554344</signalValue>
          <signalUnits>nd</signalUnits>
          <tol>0.000001</tol>
        </signal>
        <signal>
          <signalName>aeroBodyMomentCoefficient_Pitch</signalName>
          <signalValue>-0.10638585796503</signalValue>
          <signalUnits>nd</signalUnits>
          <tol>0.000001</tol>
        </signal>
      </checkOutputs>
    </staticShot>
  </checkData>

The internalValues element, if present, usually is a list of all model-defined internal variable values. This is normally not required for a model exchange, but such information is very useful to aide in debugging the implementation by the recipient.