SCOPFLOW with EMPAR solver always reports CONVERGED, does not enforce N-1 security

[samimk]

Issue applies to:

• pflow
• OPFLOW
• TCOPFLOW
• SCOPFLOW
• SOPFLOW
• CMake and build system
• Spack
• Visualization
• Documentation
• Other

Summary

The EMPAR (embarrassingly parallel) solver for SCOPFLOW always reports CONVERGED status regardless of whether individual contingency subproblems actually converged. This makes it impossible to determine N-1-secure loadability limits when using EMPAR, and produces misleadingly optimistic results compared to the IPOPT solver.

Description how to reproduce the issue

Description

When SCOPFLOW is executed with the EMPAR solver (multi-core), the function SCOPFLOWSolverGetConvergenceStatus_EMPAR always returns PETSC_TRUE:

File: src/scopflow/solver/empar/scopflow_empar.cpp (lines 147–155)

PetscErrorCode SCOPFLOWSolverGetConvergenceStatus_EMPAR(SCOPFLOW scopflow,
                                                         PetscBool *status)
{
  (void)scopflow;
  PetscFunctionBegin;
  *status = PETSC_TRUE;
  PetscFunctionReturn(0);
}

This means:

1. SCOPFLOW always prints Convergence status CONVERGED when using EMPAR, even when individual OPFLOW subproblems fail to converge.
2. The base-case solution is printed as if it were N-1-secure, but EMPAR solves each contingency as an independent OPFLOW subproblem and never couples the results back to adjust the base-case preventive dispatch.
3. EMPAR does not implement preventive SCOPFLOW — it solves a sequence of corrective (post-contingency) OPFLOW problems without ensuring a single base-case dispatch satisfies all contingencies simultaneously.

Observed Impact

Running SCOPFLOW on the same network (case9mod) with the same goal (maximum N-1-secure loadability) produces dramatically different results:

Solver                                Loadability Boundary	          What it actually measures
IPOPT (single-core)          ~1.40× base load	                  True N-1-secure limit (base case + all contingencies solved simultaneously)
EMPAR (10-core)	             ~2.92× base load	                  Base-case feasibility only (no N-1 security verification)

The EMPAR result is ~2× higher because it only checks whether the base case OPF converges, not whether the dispatch survives contingencies.

Additionally, EMPAR does not produce IPOPT's EXIT: status line in its output, so downstream tools cannot distinguish between optimal and non-optimal subproblem solutions.

Steps to Reproduce

1. Run SCOPFLOW with EMPAR on any network with a contingency file:
   scopflow -netfile case9mod.m -ctgcfile case9mod.cont -scopflow_solver EMPAR
2. Scale loads aggressively (e.g., 3× base load) — SCOPFLOW reports CONVERGED with 0 infeasible solutions even though it should not be N-1-secure.
3. Compare with IPOPT on the same case at the same load level — IPOPT correctly reports DID NOT CONVERGE.

ExaGO version

current main branch

System and environment details

• ExaGO version: current main branch
• Solver: EMPAR (multi-core SCOPFLOW)
• Network: case9mod
• Observed on both OpenSUSE Leap 15.6 and standard Linux distributions

Additional information

No response

Possible fix or workaround

Suggested Fix

SCOPFLOWSolverGetConvergenceStatus_EMPAR should aggregate individual OPFLOW subproblem convergence statuses:

PetscErrorCode SCOPFLOWSolverGetConvergenceStatus_EMPPAR(SCOPFLOW scopflow,
                                                          PetscBool *status)
{
  // Check each OPFLOW subproblem's convergence status
  // Return PETSC_TRUE only if ALL subproblems converged
  // Return PETSC_FALSE if any subproblem failed to converge
}

Additionally, EMPAR should either:

• (Option A) Track each subproblem's OPFLOWSolve return status and report DID NOT CONVERGE if any contingency subproblem fails, or
• (Option B) Implement the preventive coupling (adjusting the base-case dispatch based on contingency results), which would make EMPAR a true security-constrained solver.

Workaround

External tools (like LLM-Sim) can partially mitigate this by:

• Checking power balance (generation must exceed load) to flag physically impossible solutions
• Warning users that EMPAR results reflect base-case feasibility only, not N-1-secure loadability
• Preferring IPOPT for any N-1 security analysis
• However, the correct fix needs to be in ExaGO itself.

[pelesh]

Thanks @samimk for reporting this issue. I hate to say this but what you pinpointed is a feature, not a bug. SCOPFLOW module uses 3 solvers:

• Ipopt: Assembles all contingencies in a single coupled system and performs optimal power flow analysis. This is rigorous approach but does not scale because there are no scalable linear solvers that can handle ill-conditioned linear systems that arise in interior point method.
• HiOp: Uses primal decomposition to break the problem in two levels -- base case and contingencies. Computes solution by iterating between the two levels until all converge.
• EMPAR: Runs all contingencies decoupled in an embarrassingly parallel fashion. It does not check if individual contingencies converged. The assumption is that the user will postprocess outputs of individual contingencies.

I agree, returning true for convergence is misleading. We should perhaps add a summary report stating how many contingencies converged.

CC @nkoukpaizan