Fix divergence case

[MartinBelthle]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?

AlgoLeague ticket 129.

What kind of change does this PR introduce?

Bug fixes

What is the current behavior?

Part 1 : If the RAO does a second preventive and fallbacks to the initial situation in the end, it encounters this error :
The RaoResult object should not be modified outside of its usual routine.
It's because its variable optimizationStepsExecuted went from FIRST_PREVENTIVE_ONLY to SECOND_PREVENTIVE_FELLBACK_TO_INITIAL_SITUATION which was not allowed.

Part 2 :

1. The method getVirtualCost() of the class SkippedOptimizationResultImpl returns 0.
2. The method getVirtualCost("sensitivity-failure-cost") returns 0.
3. When merging preventive and curative perimeter, we filter out contingencies with a load flow divergence.

Example:

CASTOR applies PRAs. These actions make a contingency perimeter "Co-1 curative" diverge.
So, it skips this perimeter and marks it as a SkippedOptimizationResultImpl.
When merging preventive and curative perimeters, it filters out this perimeter from the cost evaluation.
This means even though CASTOR made a perimeter diverge, in the end it does not see it.
To correct this behavior, we also have to change the value returned by the 2 methods getVirtualCost as even if CASTOR considered this perimeter it would still not see the virtual cost associated.

What is the new behavior (if this is a feature change)?

Part 1 : The exception no longer occurs as this change is allowed.

Part 2 :

1. The class SkippedOptimizationResultImpl now has a variable sensitivityFailureOvercost which corresponds to the one filled in the RAO Parameters. The method getVirtualCost() now returns this cost. The same goes for getVirtualCost(virtualCostName) which returns sensitivityFailureOvercost if called with "sensitivity-failure-cost" and 0 otherwise.
2. When merging preventive and curative perimeter, we do not longer filter out contingencies with a load flow divergence.

So, if the same example occurs, the RAO will go through every contingency perimeter and for the ones with loadflow divergence, it will add the sensitivityFailureOvercost to the virtual cost.

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

Other information:

The farao-cucumber-branch swe-divergence contains a test case and every test passed on Jenkins.

[pet-mit]

throw exception instead (we do it elsewhere when the parameter is wrong, for example in setPstSensitivityThreshold)

[MartinBelthle]

I talked about it with Philippe and we copied the logic of the method setCurativeMinObjImprovement in class ObjectiveFunctionParameters. I can modify the code but I prefer that you discuss it with him before.

[pet-mit]

ok then, for now. but i think we should harmonize the parameters more, and see what is done in other powsybl projects