Common nomenclature: flight states/points

[MarAlder]

Problem description

Before freezing the nomenclature of the CPACS 3.3 relase candidate, we should reconsider whether we can still unify the naming. A feedback after the last stakeholder meeting concerns the definition of flight states. We are currently having the implementations listed below.

As there might be more disciplines which need a flight state/point definition, we should agree on what philosophy we want to apply here in the future. I see three possibilities wrt defining the flight states, and maybe in general as well:

1. We keep each discipline as flexible as possible and allow individual naming within the corresponding analysis node.
2. We try to align the naming across the analysis nodes but each discipline still has its own flight state definition.
3. We are trying to define the flight states outside of the individual disciplines so that multiple disciplines can access pre-built flight states via uID. A suggestion from the community suggests /cpacs/flightXXX, it would also be conceivable to use the global node in the Analyses node. It may increase the consistency, but also increase complexity and maybe reduce the flexiblity (see the differences in the following implementations).

From the perspective of the CPACS coordination, I do not want to prescribe any philosophy but rather try to achieve a collaborative best-practice agreement. Therefore I'm very glad for any response.

Current 3.3-beta implementations

analyses/aeroPerformance: boundaryConditions

Note: As it is already introduced, we could should not change it in a minor release but append a documentation note that the naming is equivalent to our chosen naming convention and will be adopted in the next major release.

loadCases: flightPoint

aeroCases: state

[MarAlder]

A realization of the third option could be a pre-definition similar to cpacs/performanceCases:

• aeroCases: must link this element and append it by angles and roll rates
• loadCases: could also link these nodes (I just notice that we should also apply the environmentalConditionsType instead of defining atomsphericModel and deltaTemperature...)
• trimCases: The proposal actually derives from ../aircraft/model/performanceRequirements/trimCases/trimCase, where flightCaseUID has no proper target yet
• aeroPerformance: not applicable

[MarAlder]

Today we identified some pro's and con's for the above proposal collecting flightCases (could also be named flightPoints) under the /cpacs root node:

pro	con
independent from a specific aircraft configuration and therefore allows consistent reuse in different vehicles	flightCases as defined above just represent a reduced set of the information which is needed for other analysis (e.g., aeroCases needing roll rates and other inputs to define a flight case)
.../model/analysis/flightDynamics/trimCases (linking flightCases through ../model/performanceRequirements/trimCases would benefit when defining multiple trim cases for a smaller set of pre-defined flightCases	users might specify data which which is not processible for other analysis tools (e.g., flightLoadCases currently only require a machNumber, whereas a choice between calibratedAirSpeed or trueAirSpeed would then also be possible and should be processable by the load analysis tools)
future definitions could use these flightCases as well	some analysis nodes do not distinguish between input and output (the flightState in load/aeorCases are an output of one discipline while at the same time being input for an aero tool)

to be continued when we collect more ideas..

As a general CPACS philosophy we propose: Vehicle independent nodes should be predefinable under the CPACS root element if the advantage of its reusability (either through the consistent reuse for different aircraft/helicopter or through reducing of specification effort due to its complexity) is larger than the disadvange arising from additional effort to further enrich the data or the increased complexity due to linking.

It might also be an option to only implement and use cpacs/flightCases for .../model/analysis/flightDynamics/trimCases analysis and potentially other implementations in future, while other discipline use a similar, but independent local data structure where just the nomenclature is synchronized.

[HHOPs]

Recap of the flightCases from an "as-is" perspective - e.g. CPACS 2.3 - being under cpacs/vehicles/aircraft/model/analyses/flightDynamics:

<flightDynamics>
  <flightCases>
    <flightCase uID="FlightCaseCruise">
      <name>FlightCaseCruise</name>
      <description>Design Point Cruise</description>
      <weightAndBalanceUID>WB_MTOM-GU</weightAndBalanceUID>
      <standardAltitude>11000</standardAltitude>
      <mach>0.8</mach>
      <vCAS>136.43</vCAS>
      <configuration>0</configuration>
      <gear>0</gear>
      <airportUID>Airport_EHAM</airportUID>
      <runwayUID>EHAM-24</runwayUID>
      <linearModel>
        <Alon mapType="vector">0;-1.58889269017399e-005;0.00
        <Blon mapType="vector">0;1.09450863479668;-19.413756
        <Clon mapType="vector">0;0.999999999506952;0;0;3.784
        <Dlon mapType="vector">0;0;0;0;0;0;1.9826739142799;0
        <Alat mapType="vector">-0.00221497907913215;-1.56837
        <Blat mapType="vector">-0.271438669709361;0;0;3.7113
        <Clat mapType="vector">0;0;0;0;0.00423600275532621;0
        <Dlat mapType="vector">0;0;0;0;0;0;0.027721289263166
      </linearModel>
      <trimResult>
        <mach>0.799984447851245</mach>
        <vTAS>236.051005842601</vTAS>
        <alpha>3.94670958132179</alpha>
        <altitude>11000.0000012638</altitude>
      </trimResult>
    </flightCase>
...

A separation of the trim requirements (configuration node, weight & balance, aircraft performance requirements) and the respective results (trimResultand linearModel) is highly recommended - as long as the required inputs for the trim solution can be derived from these definitions. As I understand, this should be the case with the proposed definition ("vehicle independent") via cpacs/flightCases.

I propose the trim and linearization results to still target into the analyses section - see the example above for the respective content.

For all other matters I'm fully open to any common nomencalture in CPACS - as long as it allows for a complete definition of trim cases...

[MarAlder]

We agreed on:

• point is a point in a parameter space
• case is a description for more complex data structures such as used for analyses
• flightPoints will be seperated from a specific aircraft and placed under vehicles node