[Security analysis] Richer computation status in results

[sylvlecl]

• Do you want to request a feature or report a bug?

Feature

• What is the current behavior?

For pre-contingency and each post-contingency result, we only have a computationOk boolean which tells us if the computation was performed and successfully executed.

• What is the expected behavior?

We could get more information, when the simulation could not be executed for a particular contingency, about the "why" it was not simulated. Reasons could include :

• Network modelling does not allow the element to be switched off.
• Element is already disconnected in the base case.
• Element is outside the main connected component of the Network.

• What is the motivation / use case for changing the behavior?

Being able to know why post contingency results could not be computed, in order to assess what can be done (should it be considered a "normal" case, or should the user do something to fix it ...)

• Design

First, computationOk flag is currently at the LimitViolationResult level : it would be more relevant to move it to the containing PostContingencyResult or PrecontingencyResult.

Then we need to have a richer status field :

• do we keep the boolean nonetheless ?
• should that status report information only about the contingency "validity", or also about the reason for failed computations ? (like "maximum iteration" or something else) Else, should that kind of information go in a second status ?
• do we use an enum ? it will have the disadvantage of not be able to get implementation-specific status
• do we add an additional String message as information ?