Revision of loadCases

[MarAlder]

A working group (thanks to @CLiersch for the coordination) is currently working on adapting the existing loadCase definition to current requirements.

Many thanks to @sdeinert for the first draft. This serves well as a starting point for further iterations. To support these activities, the usual visualizations:

• XSD diagram (without types)
• XSD diagram (with types)
• Online documentation

[MarAlder]

Results of the todays working group implemented in 96e45bd:

• [x] direct specification of weightAndBalanceUID instead of mass element
• [x] loadCaseDefinition obligatory
• [x] add control Element to controlElements --> inherits from aeroPerformanceControlElementType and is extended by cabinPressure and controller
• [x] controller is enumerated list (ToDo: needs to be filled)
• [x] renamed flightState to flightPoint and reduced to atmosphericModel, deltaTemperature, altitude and machNumber
• [x] loadCondition extended by name and description
• [x] moved elements from flightState to loadCondition
• [ ] description for flightLoadCaseDefinition
• [x] add enumeration of design speeds (ToDo: check and extend if necessary)
• [x] add enumeration of gustShapes (ToDo: fill with reasonable values)

[MarAlder]

The working group on the loadCase definition has agreed on a proposal that will now be presented to the community. This is a fundamental change to the loadCase definition, so this issue is a breaking change and requires special attention before it is introduced into the official release. CPACS <= 3.2 will not be valid anymore after introducing this proposal.

What has been changed

• The flightLoadCases and groundLoadCases (they now have the same type) have been redefined:
  • XSD diagram old schema vs new schema
  • documentation old schema vs new schema
• The aerodynamic data for the loadCases have been redefined:
  • XSD diagram old schema vs new schema
  • documentation old schema vs new schema
• The reference points at which the loads are applied (previously called dynamicAircraftModel under wing and fuselage) are renamed moved to the analysis node (introduced a new global node):
  • XSD diagram old schema vs new schema vs new schema
  • documentation old schema vs new schema

The latest changes are introduced in the loadCases branch.

Next steps

• [x] inform stakeholders (@MarAlder)
• [x] add/check documentation of new types listed below (@CLiersch, all)
• [x] add example file and unittest (@MarAlder)

Deleted and added types compared to CPACS 3.2:

deleted types

• additionalParameterType
• additionalParametersType
• aeroDataSetForLoadsType
• aeroDataSetsForLoadsType
• angleAccelerationType
• angleDisplacementType
• atmosphericConditionsType
• attitudeAndMotionType
• coefficientsType
• controlInputType
• controlInputsType
• controlSurfaceDeflectionType
• controlSurfaceDeflectionsType
• cutLoadType
• cutLoadsType
• engineSettingType
• flightLoadCaseType
• flowConditionType
• fuselageCoefficientsType
• fuselageSegmentCoefficientsType
• fuselageSegmentStripCoefficientsType
• fuselageSegmentsCoefficientsType
• fuselagesCoefficientsType
• genericComponentCoefficientsType
• genericComponentsCoefficientsType
• groundLoadCaseType
• landingGearSettingType
• loadCaseEnginesType
• loadCaseLandingGearsType
• loadCaseMassType
• loadCaseRotationType
• loadCaseRotationVelocityType
• loadCaseSettingsType
• loadCaseStateType
• loadCaseTranslationAccelerationType
• loadCaseTranslationType
• loadCaseTranslationVelocityType
• loadConditionType
• loadReferenceType
• nodalLoadType
• nodalLoadsType
• quasiSteadyRotationType
• trimParametersType
• wingCoefficientsType
• wingSegmentCoefficientsType
• wingSegmentStripCoefficientsType
• wingSegmentsCoefficientsType
• wingsCoefficientsType

added types

• aeroCaseAeroDataType
• aeroCaseCoefficientsType
• aeroCaseEnvironmentType
• aeroCaseStateType
• aeroCaseType
• aeroCasesType
• aeroDataAircraftType
• aeroDataComponentType
• aeroDataComponentsType
• aircraftAnalysesGlobalType
• aircraftConfigurationType
• aircraftConfigurationsType
• aircraftControlElementType
• aircraftControlElementsType
• atmosphericModelType
• cabinPressureType
• cabinPressuresType
• chordwisePartType
• chordwisePartsType
• coefficientReferenceType
• coefficientsBreakdownComponentType
• coefficientsBreakdownComponentsType
• coefficientsBreakdownSegmentType
• coefficientsBreakdownStripType
• coefficientsBreakdownStripsType
• coefficientsBreakdownType
• coefficientsBreakdownWingSegmentsType
• coefficientsBreakdownWingType
• coefficientsBreakdownWingsType
• dragFractionsType
• flightLoadConditionType
• flightLoadsType
• loadApplicationPointSetType
• loadApplicationPointsType
• loadCaseAccelerationsType
• loadCaseDefinitionType
• loadCaseFlightPointType
• loadCaseGustType
• loadCaseSuperpositionType
• loadCaseType
• loadSetsType
• loadsType
• remaningContributionsType

[MarAlder]

I changed the loads envelope from

to

to account for the control surfaces. Alternative would be to add controlSurfaceCutLoadsEnvelope, but we have chosen the more flexible way throughout our loads definition as well.

[MarAlder]

I revised the documentaion and implemented a proposal from DLR-AE for loadEnvelopes and convex hull definitions with d0cd75f.

There are some open TODOs for DRL-AE, @CLiersch and DLR-SR concerning documentation and naming issues (parse for TODO: in the schema) we need to resolve before the official release:

• [ ] (DLR-AE) check renaming of loadsEnvelope to loadEnvelopes
• [ ] (DLR-AE) Can convexHull be replaced with more meaningful name?
• [ ] (DLR-AE) check convexHull child elements
• [ ] (DLR-AE) More meaningful summary for loadEnvelopeConvexHullType
• [ ] (DLR-SR) Gust shape enumeration: Are these options clear or do we need further descriptions or illustrations?
• [ ] (DLR-SR) Gust shape parameteres: Is this difinition sufficient and clear? Are some CS25 values (referenceGustVelocity, gustGradientDistance, designGustVelocity) required?
• [ ] (@CLiersch) aeroData: the term data always seems quite unspecific to me (data can be everything). Renaming?
• [ ] (@CLiersch) vehicle instead of aircraft in aeroCase to make it applicable for helicopters as well?
• [ ] (@CLiersch) better description for aeroDataComponentType
• [ ] (@CLiersch) check element description in aeroCaseCoefficientsType
• [ ] (@CLiersch) improve remarks in chordwisePartsType
• [ ] (@CLiersch) name element really required in remaningContributionsType

There was no negative feedback from the community, so I will merge the proposal back to develop.

[MarAlder]

Closed. Remaining issue discussed in #659.