Harmonization of the nomenclature

[MarAlder]

With regard to the CPACS 3.3 release, some larger adjustments and enhancements such as aeroCases, loadCases and missionDefinitions or pointPerformances were discussed. During and after the stakeholder meetings there were some requests to harmonize the nomenclature before the official finalization. This issue will summarize the major changes:

Naming conventions:

I added the proposed development guidelines (#704) to development.md. The proposed naming conventions are applied in a common structure for analysis elements:

The figure below shows an example of a typical analysis node. A complete analysis case is summarized with case. There is no need for a plural parent element ..Cases if there exists no alternatives. In other words, if myDiscipline groups different analysis cases, a plural parent element should be applied (e.g., flightDynamics: trimCases, controllabilityCases, etc.). In addition to a uID attribute as well as the usual name (obligatory) and description (optinoal) elements, a case consists of two parts.

The first part should be labeld as specification and contains the input parameters for the corresponding analysis (since these may represent an output for other disciplines, the name input should be avoided at this point; also the term definition is a bit too imprecise). There are a few typical elements which should be reused for the specification if it makes sense. This includes an environment element of type environmentType, which provides an atmosphericModel and a corresponding deltaTemperature. A node named configuration of type configurationType provides a uID reference to predefined configurations as well as additional individual control devices that can be superposed to this configuration. This set of inputs might be further enriched by own parameters such as uID references to existing components or individual parameters based on the simple baseTypes.

The second part contains the actual analysis data and its name may depending on the discipline (myResults used as a placeholder).

The naming conventions and harmonization of analysis elements will affect the following implementations:

aeroCases

before:

after:

flight/groundLoadCases

before:

after:

aeroMaps (will not be part of CPACS 3.3!)

We also propose to harmonize the aeroMaps in a future release:

now:

future:

Summary of analyses nodes

So I would say it looks really harmonic:

missionDefinitions

before:

after:

pointPerformances

before:

after:

[ErwinMoerland]

Hi @MarAlder, looks good and makes the structure much more clear! I am very happy with the creation and application of the common nomenclature as well as with the more harmonized common structure of analysis node contents .

One thing to consider to further harmonize the <analysis> node contents:

"The second part contains the actual analysis data and its name may depending on the discipline (myResults used as a placeholder)."

for myResults we now have:

<aeroCase>-> <aeroData> <flightLoadCase>, <groundLoadCase>, <crashLoadCase> -> <loads> <aeroMap> -> <aeroPerformanceMap>, <aeroLimitsMap>

should we provide a hint on naming conventions for the myData node? We can distinguish two kinds of result nodes: data and maps. Then we could have the following:

<aeroCase>-> <aeroData> <flightLoadCase>, <groundLoadCase>, <crashLoadCase> -> <loadData> <aeroMap> -> <aeroPerformanceMap>, <aeroLimitsMap>

i.e.: the xxxData and xxxMap represent the base nodes for the actual analysis data. This convention could be used throughout the complete <analysis> node

[MarAlder]

Good suggestion!

[MarAlder]

Implemented via e485289 (see development.md)

[MarAlder]

No feedback; so I assume everything is harmonic now :)