Understanding the process numbers returned by BLACS_PNUM (ScaLAPACK)

[OP1]

The following code (built with ifx 2025.2.1 on Windows and run with 6 processes) produce somewhat puzzling information, and we would like to get some clarity on the behavior we observe.

The code uses BLACS_GRIDMAP to create a custom 1x4 grid from processes 2, 3, 4 and 5 (thus, process 0 and 1 are not part of that grid). Then a process that is in that grid (process 2) calls BLACS_PNUM to retrieve the numbers of all the processes that are in that grid.

Instead of the expected output of -1, -1, 2, 3, 4, 5, we get 0, 1, 2, 3, -1, -1. 

Can somebody explain this? Are process numbers defined within the context of a particular grid, or are they global?

PROGRAM P
IMPLICIT NONE (TYPE, EXTERNAL)
EXTERNAL :: BLACS_GET,  BLACS_PINFO, BLACS_PNUM, BLACS_GRIDMAP, BLACS_GRIDINFO
INTEGER(KIND = 8) :: BLACS_PNUM, CTXT_SYS, C_TXT, MY_PROC, N_PROCS, UMAP(1, 4), I, NPROW, NPCOL, MYROW, MYCOL
CALL BLACS_PINFO(MY_PROC, N_PROCS)
IF (N_PROCS /= 6) THEN
    WRITE(*, '(A)') 'Run this program with 6 processes!'
    STOP
END IF
CALL BLACS_GET(0, 0, CTXT_SYS)
C_TXT = CTXT_SYS
UMAP(1, :) = [2, 3, 4, 5]
CALL BLACS_GRIDMAP(C_TXT, UMAP, 1, 1, 4)
IF (MY_PROC == 2) THEN
    CALL BLACS_GRIDINFO(C_TXT, NPROW, NPCOL, MYROW, MYCOL)
    WRITE(*, *) 'Process number : ', MY_PROC, 'Process row: ', MYROW, 'Process column: ', MYCOL
    WRITE(*, *) 'Other processes: ', (BLACS_PNUM(C_TXT, 0, I), I = 0, N_PROCS - 1)
END IF
END PROGRAM P

[sc_Intel]

The output 0, 1, 2, 3, -1, -1 is correct. According to the oneMKL BLACS documentation (https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-fortran/2025-2/blacs-pnum.html), BLACS_PNUM returns "the system process number of the process at {PROW, PCOL} in the process grid" - meaning the numbering is grid-relative, not global ones.

When you call BLACS_GRIDMAP with processes [2, 3, 4, 5], it creates a new context and remaps them: global process 2 → grid process 0, 3 → 1, and so on. The -1 values indicate invalid positions (your grid is 1×4, so columns 4–5 don’t exist).

This abstraction ensures BLACS operations use clean 0-based grid numbering regardless of the underlying layout.

One correction to the minor issue in the code: INTEGER, EXTERNAL :: BLACS_PNUM instead of INTEGER(KIND=8) :: BLACS_PNUM.

If you need to map between grid and global process numbers, you’ll need to maintain your own mapping array.

[OP1]

Thanks @sc_Intel for the clarification. We will create our own process map to describe the relationship between global process numbers (on which we distribute various kind of data) and local grid(s) process numbers.

Regarding the INTEGER(KIND = declaration, we use the ilp64 interface to the ScaLAPACK library, so isn't it necessary in this case?

[sc_Intel]

Thank you for clarifying. My earlier suggestion was based on an LP64 build. For ILP64, 64-bit integers are required, so your original declaration using INTEGER(KIND=8) is correct.