PDSYEVR (ScaLAPACK, LP64) returns INFO=0 with M=0 on a single MPI rank, and prints "DSTEGR2 paramete

[rizzo]

Hello,

I've hit what looks like a defect in MKL's ScaLAPACK `pdsyevr` on a single MPI rank. A self-contained reproducer (two small Fortran programs + the stored matrices) is attached as mkl_pdsyevr_dstegr2_report.zip; REPORT.md inside has the full write-up.

**Summary**

`pdsyevr` ("V", "A", "L"), called on a specific 240x240 real symmetric standard-form matrix on a 1x1 BLACS grid (one MPI process, `OMP_NUM_THREADS=1`), prints an internal diagnostic

```

{ 0, 0}: On entry to

DSTEGR2 parameter number -202 had an illegal value

```

and then returns `INFO = 0` with the eigenvalue count `M = 0` instead of `M = 240`. The eigenvalues written to `W` are nevertheless correct (they agree to machine precision with 2- and 4-process runs of the same matrix), so the computation itself completes; only the returned count `M` is wrong and an unexpected PXERBLA-style message is emitted for an internal routine. The same call on the same matrix at 2 and 4 processes is clean (`INFO = 0`, `M = 240`, no message). The single-rank failure is deterministic — 20 of 20 runs.

**Why I think this is a defect**

1. For `RANGE = "A"`, a successful `pdsyevr` (`INFO = 0`) should return `M = N`. Returning `M = 0` with `INFO = 0` gives the caller no way to detect the failure. A caller that sizes downstream work from `M` — e.g. the number of eigenvector columns to back-transform in a generalized problem — then silently processes zero eigenvectors with no error indication. That is exactly how it first surfaced for me (in a generalized eigenproblem inside a larger application).

2. The parameter index `-202` is not a valid argument position for `DSTEGR2` (it has far fewer than 202 arguments), so this is not a caller-facing argument error; it indicates MKL's internal MRRR path invoked `DSTEGR2` with an argument that failed the routine's own validation. Because the public `pdsyevr` arguments are valid and documented — byte-identical to the 2- and 4-process calls that succeed — the inconsistency is internal to the single-process MRRR code path.

**Environment**

- MKL 2025.3, Product Build 20251007, LP64 interface (`libmkl_scalapack_lp64`, `libmkl_blacs_intelmpi_lp64`, `libmkl_intel_lp64`).

- Threading layer `libmkl_intel_thread` with `OMP_NUM_THREADS=1`.

- Intel MPI (oneAPI 2025.3), `ifx` via `mpiifx`.

- Host: 2x AMD EPYC 9654 (Genoa), Linux.

**Reproducing (from the attached zip)**

```

./build.sh

export OMP_NUM_THREADS=1

mpiexec -n 1 ./mrrr_repro_evr mrrr_aprime.bin # message + INFO=0, M=0

mpiexec -n 2 ./mrrr_repro_evr mrrr_aprime.bin # clean, INFO=0, M=240

mpiexec -n 4 ./mrrr_repro_evr mrrr_aprime.bin # clean, INFO=0, M=240

```

`mrrr_repro_evr` reads one stored 240x240 matrix and makes a single `pdsyevr` call (workspace sized from the `LWORK = -1` / `LIWORK = -1` query, then zero-initialized). Call arguments: `JOBZ="V"`, `RANGE="A"`, `UPLO="L"`, `N=240`, `IA=JA=IZ=JZ=1`, `VL=VU=0.0`, `IL=1`, `IU=240`, block size `MB=NB=32`. A second program, `mrrr_repro`, runs the full `pdsygst(1,"L")` -> `pdsyevr("V","A","L")` sequence from the stored Hamiltonian and Cholesky factor and prints the identical message.

Observed `np = 1` output:

```

Intel(R) oneAPI Math Kernel Library Version 2025.3-Product Build 20251007 for Intel(R) 64 architecture applications

n=240 mb=32 nb=32 nproc=1

pdsyevr query info=0

{ 0, 0}: On entry to

DSTEGR2 parameter number -202 had an illegal value

pdsyevr info=0 m=0

w(1)= -9.252989077474355E-01 w(n)= 9.457626123323363E-01

```

The eigenvalues match the `np = 2` run in the leading digits, confirming the spectrum is computed correctly; only `M` and the spurious message are wrong. The matrix has tightly clustered eigenvalues in this case, which is the regime that stresses the MRRR algorithm `DSTEGR2` implements.

**Question / requested resolution**

Is this a known issue, or is there something in the single-process argument setup I should be doing differently? If it is a defect, I'd expect either (a) `pdsyevr` to return the correct `M = N` on the 1x1 grid and suppress the spurious message, or (b) if the internal argument inconsistency is genuine, for it to surface as a non-zero `INFO` rather than `INFO = 0` with `M = 0`.

Happy to provide any further detail. Thanks.

[Sergey_K_Intel1 · Accepted solution]

First of all, we'd like to notice that info=-202 has nothing to do with the diagnostics. info=202 means an internal algorithmic failure. So the error message
"DSTEGR2 parameter number -202 had an illegal value" is a misleading one and it should be replaced with more informative message. Certainly we will work to improve error messages in the future.  PDSYEVR returns M=0 in this case because the DSTEGR2 returned the error code, PDSYEVR exited without computing the eigenvectors.

The MRRR pdsyevr eigensolver has been using LDLT factorization of tridiagonal matrix (T - sigma I) to separate an eigenvalue from already computed eigenvalues with the help of very small shifts. And info=202 means that it failed to compute an approximation to eigenvalue with prescribed accuracy withing preset 6 possible shifts (there is an internal parameter MAXTRY in the ScaLAPACK dlarre2 routine which is set to 6) since the matrix has tightly clustered eigenvalues. It should be stressed that the algorithm is very sensitive to round-off errors and the algorithm for reduction to tridiagonal form depend on OS, Cpu type, compiler options and etc. and this explains different results for np=1, np=2 and np=4. We've not able to reproduce the failure so far and taking into account out-of-order executions, chances to run into the same failure are pretty low. We can increase the value of the internal parameter MAXTRY as the authors of the MRRR algorithm recommend in these cases but there is no guarantee it will help.

We'd like to recommend using ScaLAPACK PDSYEV or PDSYEVX for matrices with tightly clustered eigenvalues since these routines are more reliable for such cases.

Thanks

Sergey

[tomcary]

This certainly looks suspicious, especially since the behaviour is deterministic on a 1×1 BLACS grid while the same inputs work correctly with multiple MPI ranks. The combination of INFO = 0, correct eigenvalues, and M = 0 is particularly concerning because downstream code has no reliable way to detect that something went wrong. Returning a successful status while reporting zero eigenpairs for RANGE="A" seems inconsistent with the documented interface. The -202 diagnostic also suggests the issue is arising within the internal MRRR path rather than from the public API arguments. Thanks for providing such a thorough reproducer having both the minimal case and environment details should make this much easier to investigate.