Currently, the mapping was set by node. That is NOT the same thing as…

… compact process binding, since for e.g. 2 nodes 4 tasks it will lead to task 0 on node 0, task 1 on node 1, task 2 on node 0, task 3 on node 1. Compact would have been task 0 and 1 on node 0, and task 2 and 3 on node 1. Thus, this was a bug. Mapping by slot (combined with specifying PE=n) IS correct. The PE=n will set cpus-per-rank to n (see https://www.open-mpi.org/doc/current/man1/mpirun.1.php), while mapping by slot will mean that each rank is mapped to a consecutive slot. The only scenario in which mapping by slot will result in non-compact mapping is if oversubscription is enabled - then the oversubscribed ranks will be assigned round robin to the slots.

eessi/testsuite/hooks.py

@@ -436,7 +436,7 @@ def set_compact_process_binding(test: rfm.RegressionTest):
     # Other launchers may or may not do the correct binding
     test.env_vars['I_MPI_PIN_CELL'] = 'core'  # Don't bind to hyperthreads, only to physcial cores
     test.env_vars['I_MPI_PIN_DOMAIN'] = '%s:compact' % physical_cpus_per_task
-    test.env_vars['OMPI_MCA_rmaps_base_mapping_policy'] = 'node:PE=%s' % physical_cpus_per_task
+    test.env_vars['OMPI_MCA_rmaps_base_mapping_policy'] = 'slot:PE=%s' % physical_cpus_per_task
     # Default binding for SLURM. Only effective if the task/affinity plugin is enabled
     # and when number of tasks times cpus per task equals either socket, core or thread count
     test.env_vars['SLURM_CPU_BIND'] = 'verbose'