search

DLR-SL / CPACS

CPACS - Common Parametric Aircraft Configuration Schema
http://dlr-sl.github.io/CPACS/
Apache License 2.0
79 stars 38 forks source link

PointPerformanceDefinitions: doubleConstraintBaseType #715

Open MarAlder opened 3 years ago

MarAlder commented 3 years ago

cpacs/vehicles/aircraft/performanceCases/pointPerformanceDefinitions/pointPerformanceDefinition

Currently the constraints in the pointPerformanceDefinitions use the doubleConstraintBaseType, i.e. the user must provide the relationalOperation attribute (eq, le, ...).

As it causes some effort to account for the relational attributes when integrating tools the question arises whether it is necessary to provide this information at this point? Or is eq the standard case?

Solutions

It would be good to get feedback from the experts using this node. @hhops, @erwinmoerland

ErwinMoerland commented 3 years ago

In the first effort to create a consistent version of the performanceCases node, the constraints nodes in both the pointPerformanceDefinitions and missionDefinitions were completely aligned (i.e.: both feature the same Children and have the relationalOperator as attribute). For CPACS-simplicity, it would be good if the nodes stay aligned. However, if the relationalOperator really does not make any sense for the pointPerformanceDefinitions, it seems superfluous and might be removed.

Reaction to the proposed solutions:

relationalOperator could be removed assuming eq as the only relevant one

ok, if this assumption is indeed always the case for pointPerformanceDefinitions (needs confirmation). @CarstenChristmann, can you confirm this? We then need to distinguish a doubleConstraintWithRelationalOperatorBaseType and a doubleConstraintBaseType

relationalOperator could be optional (with eq as default)

I have checked the missionDefinitions node for the 5 missions of the Diabolo project (see Issue #716). There are quite some segments which have constraints on the machNumber, altitude, loadFactor, etc. Since the value of the relationalOperator attribute differs quite a lot across the different segments (i.e.: switches between "le", "eq", "ge"), setting a default value does not seem appropriate. Anyway: making the attribute optional does not seem to resolve having to check it's existence or not?

leave it as it is implemented in the current RC

fine for me as well, as it provides simplicity in definitions within CPACS itself.

MarAlder commented 3 years ago

We decided to continue with the RC implementation (option 3) as first tests have been conducted with this. I'll keep the issue open for further revisions in an upcoming release.