Evolution of the sensitivity analysis ResultWriter and Result to support multi-component computation, improve diagnostic and support cancel

[snoopfab]

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)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?

powsybl/powsybl-core#3626

What kind of change does this PR introduce?

Implement features:

• Enable to add multi-component support for sensitivity analysis inOpenLoadFlow
• Enable to return partial results in case of interruption
• Enable a better diagnosis of contingency failure

What is the current behavior?

powsybl/powsybl-core#3626

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

• Enable to add multi-component support for sensitivity analysis inOpenLoadFlow
• Enable to return partial results in case of interruption
• Enable a better diagnosis of contingency failure

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

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

[sonarqubecloud]

Quality Gate failed

Failed conditions
78.7% Coverage on New Code (required ≥ 90%)

See analysis details on SonarQube Cloud

[snoopfab]

I rebased the sensitivity-result-writer-enhancements branches of powsybl-core and powsybl-open-loadflow onto main.

The rebases were really not trivial (an automatic merge was impossible).

While my branches were under review, Geoffroy’s PR #3670 (operator strategies in the sensitivity API) was merged into core, along with its OLF counterpart #1326. These two PRs touched the same SensitivityResultWriter interface, the same SensitivityAnalysisResult class, and the same provider implementations as my work on multi‑component reporting — so we ended up with two parallel refactorings of the same surface area.

Rather than keeping the two APIs side by side, I merged my additions into the interface redesigned by Geoffroy. His design is centered around the new SensitivityState (a contingency + an optional operator strategy).

My additions — per‑component load‑flow status and partial result reporting in case of interruption — are a cross‑cutting concern that integrates naturally into this state.

So concretely, for the writer interface:

• writeSensitivityValue gained the operator strategy index via #3670; nothing new on my side.
• writeContingencyStatus and the post‑#3670 3‑argument writeStateStatus have both disappeared. They are replaced by:
  writeStateStatus(int contingencyIndex, int operatorStrategyIndex,
  Status, LoadFlowStatus, int numCC, int numCS)
  This is a merge of his “which state failed?” with my “which load‑flow status on which component?”
  Pre‑contingency reporting is done with both indices set to -1, which replaces my former writeSynchronousComponentStatus.
• computationComplete() was added.

The final proposed contract is therefore:

/**
 * @author Geoffroy Jamgotchian {@literal <geoffroy.jamgotchian at rte-france.com>}
 * @author Fabrice Buscaylet {@literal <fabrice.buscaylet at artelys.com}
 */
public interface SensitivityResultWriter {

    /**
     * In the case of multi-component computation, a factor has a variable
     * that is linked to an equipment that belongs to a single component.
     * Called once per factor and contingency in the factor context that
     * belongs to the same component as the factor equipment.
     * NaN for invalid factors whose equipment does not belong to a component
     * that has been run.
     *
     * @param factorIndex the factor index
     * @param contingencyIndex the contingency index, -1 for pre-contingency state
     * @param operatorStrategyIndex the operator strategy index, -1 if none
     * @param value the sensitivity value
     * @param functionReference the function reference
     */
    void writeSensitivityValue(int factorIndex, int contingencyIndex,
                               int operatorStrategyIndex, double value,
                               double functionReference);

    /**
     * Reports the status for a given state (contingency + optional operator strategy)
     * and a given component (numCC/numCS).
     * <p>
     * Called for every state and every numCC/numCS where the state has an impact.
     * For pre-contingency reporting, both {@code contingencyIndex} and
     * {@code operatorStrategyIndex} are -1.
     * For contingencies that are never run, called once in the end with NO_IMPACT
     * and numCC and numCS set to -1.
     *
     * @param contingencyIndex the contingency index, -1 for pre-contingency state
     * @param operatorStrategyIndex the operator strategy index, -1 if none
     * @param status the sensitivity analysis status
     * @param loadFlowStatus the load flow status for this component
     * @param numCC index of connected component, -1 if not applicable
     * @param numCS index of synchronous component, -1 if not applicable
     */
    void writeStateStatus(int contingencyIndex, int operatorStrategyIndex,
                          SensitivityAnalysisResult.Status status,
                          SensitivityAnalysisResult.LoadFlowStatus loadFlowStatus,
                          int numCC, int numCS);

    /**
     * Called at the end of the computation if the computation has not been interrupted.
     */
    void computationComplete();
}

On the result model side:

• SensitivityContingencyStatus has disappeared and is replaced by SensitivityStateStatus from #3670, and I moved the per‑component load‑flow list onto this class.
• SensitivityPreContingencyStatus has also disappeared; the pre‑contingency status is now a normal entry in stateStatuses, keyed by SensitivityState.PRE_CONTINGENCY.
• The result JSON is bumped to version 1.2; readers for v1.0 and v1.1 continue to work via the existing version‑aware deserializer.

On the OLF side:

• AC analysis received the full multi‑component restructuring (loop per component via getNetworksToSimulate, aggregation of NO_IMPACT across all components, proper reporting of pre‑contingency load‑flow failure).
• DC analysis received the same treatment. Operator strategies remain fully supported on both sides.

The tests pass: 61/61 on core, 284/284 on the OLF sensi package.

Two unrelated failures appeared, which look like upstream issues related to the core bump 7.2.0 → 7.3.0‑SNAPSHOT:

• ZeroImpedanceFlowsTest (the load flow gives 2.9 MW where 1.4 MW is expected, possibly due to the switch to JGraphT 1.5.3),
• DcSensitivityAnalysisContingenciesTest.testDebug (XML IIDM format drift; the reference file just needs to be regenerated).

Practically speaking, since the commits were squashed and the branches had already been pushed to GitHub, the remote history no longer matched what I had locally. I therefore force‑pushed on the same branch.