allocate_block_mapping() failed to assign SDP blocks to all CPUs

[vasdommes]

Example: running SDPB on 8 nodes, 16 CPUs per node, with --procGranularity 4.
Block distribution is determined by block_timings.

Some nodes are left empty, although there are more blocks than nodes.
SDPB should keep all CPUs busy, for example, assigning 16 CPUs to blocks 0 and 5, and 12 CPUs to block 1.

Output:

block_timings, ms:
26738, 26565, 560279, 83619, 304570, 32261, 73257, 2791, 4767, 170, 176, 64
Block Grid Mapping
Node	Num Procs	Cost (Per Proc)		Block List
==========================================================
0	16		35017.4			{2(117)}

1	16		19035.6			{4(90)}

2	16		5226.19			{3(59)}

3	16		4578.56			{6(51)}

4	4		8065.25			{5(38)}
4	4		6684.5			{0(35)}
4	4		6641.25			{1(35)}
4	4		1191.75			{8(20)}

5	4		697.75			{7(17)}
5	4		44			{10(4)}
5	4		42.5			{9(4)}
5	4		16			{11(2)}

6	4		0			{}
6	4		0			{}
6	4		0			{}
6	4		0			{}

7	4		0			{}
7	4		0			{}
7	4		0			{}
7	4		0			{}


Process 95 caught error message:
in allocate_block_mapping() at ../src/sdpb_util/block_mapping/allocate_block_mapping.hxx:74: 
  Assertion '!block_indices.empty()' failed:
    No SDP blocks were assigned to rank=95. node=7 node_rank=11

[vasdommes]

Same but with --procGranularity 1:

Block Grid Mapping
Node	Num Procs	Cost (Per Proc)		Block List
==========================================================
0	16		35017.4			{2}

1	16		19035.6			{4}

2	16		5226.19			{3}

3	16		4578.56			{6}

4	16		2016.31			{5}

5	16		1671.12			{0}

6	16		1660.31			{1}

7	1		4767			{8}
7	1		2791			{7}
7	1		176			{10}
7	1		170			{9}
7	1		64			{11}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}
7	1		0			{}

[vasdommes]

The reason why SDPB does not assign more CPUs to smaller blocks is because it won't lead to overall speedup (capped by larger blocks). So burning mode CPU-hours (due to communication overhead) does not make much sense.

If this is a valid behavior, then we should just print a warning and allow SDPB to run further.
Note that in this case one could argue that all blocks except for the largest one should get less CPUs as well.