Addition of controllability requirements analyses

[CarstenChristmann]

The analyses of the controllability requirements have to be saved in CPACS for further processing, i.e. sizing of control surfaces/effectors. Based on required roll authorities (roll rate, roll acceleration onset/stop) and other requirements, the corresponding moments about the axes and their coefficients are determined. It is proposed to save these in

cpacs/vehicles/model/analyses/flightDynamics/controllabilityCases/controllabilityCase

Each controllabilityCase consists of

l_onset
m_onset
n_onset
cl_onset
cm_onset
cn_onset
l_stop
m_stop
n_stop
cl_stop
cm_stop
cn_stop

[MarAlder]

First version implemented in e5c3161

Next steps

• add proper documentation
• check occurence
• example for unittests

[MarAlder]

Thanks for these comments

Addition to next steps:

• names should follow camelCase style
• rename alpha to angleOfAttack

What would be the benefit of a fqCases node? Will there be additional nodes under flyingQualities in future?

[MarAlder]

I implemented a proposal from @CarstenChristmann for renaming the controllabilityCase elements:

[CarstenChristmann]

I have now produced the first data file with the proposed new structure. In order to distinguish easier between the cases I prefer to have the flight conditions included. That means, I suggest to add the following nodes on a optional basis:

.../controllabilityCases/controllabilityCase/machNumber
.../controllabilityCases/controllabilityCase/altitude
.../controllabilityCases/controllabilityCase/angleOfAttack

[MarAlder]

I have now produced the first data file with the proposed new structure. In order to distinguish easier between the cases I prefer to have the flight conditions included. That means, I suggest to add the following nodes on a optional basis:

.../controllabilityCases/controllabilityCase/machNumber
.../controllabilityCases/controllabilityCase/altitude
.../controllabilityCases/controllabilityCase/angleOfAttack

The current status looks like this:

Or is it different from the state values in controllabilityCase because the values under pointPerformance are constraints?

[CarstenChristmann]

I am sorry, but there is a misunderstanding here. The path I have described is not unambiguous. It must read:

.../analyses/flightDynamics/controllabilityCases/controllabilityCase/machNumber
.../analyses/flightDynamics/controllabilityCases/controllabilityCase/altitude
.../analyses/flightDynamics/controllabilityCases/controllabilityCase/angleOfAttack

It is just to have flight conditions (from pointPerformanceDefinitions) and results at a glance.

[MarAlder]

Ok, but maybe just for my understanding:
we have .../analysis/flightDynamics/controllabilityCases/controllabilityCase/controllabilityCaseUID referencing the data illustrated above #638 (comment). So if machNumber in analysis can differ from the constraint given in pointPerformance, then we could simply add the nodes. Otherwise it requires a little python/TiXI script or so to get the corresponding values at a glance. Only this way we would make sure that the data is always consistent.

[MarAlder]

Exclude analysis/flightDynamics/controllabilityCases, since @CarstenChristmann wants to first test a prototype in Diabolo project. No negative feedback so far on the remaining nodes. Will be presented and discussed on developer meeting before the official release.