Aggregate results should prioritise convergence status over criteria

[FredericSabot]

When a simulation of a SA does not converge, it still check for ("FINAL") criteria. I see two issues with this

1. The convergence problems usually occur during/right after a fault => Checking a FINAL criterion does not make sense
2. In the example below (I can share the full example but it uses custom models, and the convergence problems disappear without those models), only one criterion violation is output even though all voltages are below 0.9.

Maybe the second point should be in a separate issue.

.crt busCriteria> parameters id ="Voltage limits" scope="FINAL" type="LOCAL_VALUE" uMinPu="0.9" uMaxPu="1.1"/> /busCriteria>

aggregatedResults scenarioResults id="GEN-1_0" status="CRITERIA_NON_RESPECTED"> criterionNonRespected id="node: VL-5_0 has a voltage 30.7443 kV (0.133671 pu) < 218.5 kV (0.95 pu) (criteria id: Voltage limits)" time="5.244510"/> /scenarioResults>

Note: the time="5.244" even though the simulation should run for 20s suggests a convergence issue, but is easily overlooked.

[adriguir]

I tend to agree on the first point. Nevertheless, it seems that in some operational context, there is currently both statuses available so we need to think a bit on the best way to implement this (either providing both outputs or just Divergence + some non respected criteria).

Regarding point 2., again it could be interested to have all the violations. However, the aggregatedResults is maybe not the best place for this, I need to double check because I don't remember but having maybe all the violations into the log or the timeline could also be an alternative.

Anyway, thanks for opening the issue and launching the discussions. I think we also need to discuss a bit internally (which could take a few days, with school holidays currently going on) and then we will try to propose something.

[FredericSabot]

Regarding point 2., currently only one violation is output, and the one that is output is chosen by "alphabetical" order. I think what would be best is to output the x "worst" violations, and the total/remaining number of violations (to avoid clogging the aggregated results).

Regarding the definition of "worst", there is of course multiple definitions possible, but I'd argue that the most important is to not output "caution: V_1 = 0.89 < 0.9" while the voltage at bus 2 is 0.2.

[rosiereflo]

point 2. needs to be handled in dynawo core: https://github.com/dynawo/dynawo/issues/2246

regarding point 1. we could put the status to DIVERGENCE and provide the list of failing criteria (that can be ignored if not useful)

[rosiereflo]

Final specifications:

• When a simulation is diverging and some final criteria fail then we should put the status in the aggregatedResult to DIVERGENCE + a sorted list of failing criteria
• When several criteria are failing we should give a limited sorted list of the worst cases

The behaviour of the platforms integrating dyn-algorithms should be checked after this development to avoid crashes if this is not handled in the aggregatedResult analysis.