Look into definition of "node", "server", ...

[schulzm]

Problem

During the MPI4 RC process, we saw terms like "nodes", "hosts", and "servers", etc. are used without definition, should fix this in 4.1. Indeed, the industry itself has no consistent definitions for these terms/words, and vendor hardware is changing quickly such that the specific meanings of these terms is becoming increasingly ambiguous.

As such, it's not entirely clear what exactly what the MPI standard is referring to when we use these words.

Proposal

It's difficult to straddle the line of "be vague enough to describe concepts that apply from 1994 through 2021 and beyond", but also "be clear enough to describe a specific concept."

One idea: it may be possible to define a virtual MPI architecture that could be applied to real hardware from 1994 through 2021 (and potentially beyond)...? (as of this writing, have not thought this through at all -- don't really know if it is possible or not; it's just an idea captured from the 2021 Feb meeting)

One way or another, the standard needs to crisply define what it means when it uses these terms, or it should avoid using such terms.

Changes to the Text

tbd

Impact on Implementations

likely none

Impact on Users

likely none

References and Pull Requests

tbd

[cniethammer]

For reference in future discussions:

• Within section 8.2 "Virtual Topologies", the use of "node" is defined locally and used for parts of the topology chapter, which may hide a differing global definition.

... The communication pattern of a set of processes can be represented by a graph. The
nodes represent processes, and the edges connect processes that communicate with each
other. ...

• Renaming may cause issues with Fortran 90 keyword arguments: Functions I see affected here are MPI_Dims_create, MPI_Graph_create, MPI_Graph_map, MPI_Graphdims_get that have arguments named "nnodes"

[wrwilliams]

I see three main ways in which "node" is used in the current document:

1. Chapter 8 indeed defines "node" in the "nodes and edges of a graph" sense, and appears to be internally consistent. 👍 to the topology chapter. There are scattered other uses of "node" in graph or data structure senses, most/all of which have local definitions; see below for some examples.
2. There are uses of "node" that are ambiguous as to whether they refer to a software or hardware abstraction. See for example Section 3.5: "Then it is possible that messages that match this receive are repeatedly received, yet the receive is never satisfied, because it is overtaken by other receives posted at this node (by other executing threads)." Does this refer to other receives within some MPI-defined scope (and if so, what scope?), or to receives sharing some physical hardware (and if so, what hardware)? These uses are I think the most troublesome case.
3. There are uses of "node" that seem clearly intended in the colloquial sense of "hardware node". See for example Section 2.9.1, "For example, MPI makes neither requirements nor recommendations for the output from the following program (again assuming that I/O is available at the executing nodes)." There are actually fewer instances I found where we clearly intend "hardware node" than of either case 1 or case 2.

Chapter 11 appears to both use "node" in the graph-theory sense and the hardware-descriptor sense.
Chapter 12 additionally uses "node" with a local definition in the linked-list sense.
Chapter 13 additionally uses "node" with a local definition in the binary-tree sense.

I would suggest that the unqualified term "node" be reserved for case 1 above (which should avoid interface renaming); the "node of a data structure" sense in non-normative text (and possibly even normative text) I think is also okay as long as we remain careful about providing context/scope/local definitions of terms. For case 2, if existing definitions are not sufficient and if we are really intending to talk about a software construct, "node of " can probably be meaningfully defined, but I would prefer to use existing definitions where possible. Case 3 I think should be avoided in normative text wherever possible. When it does appear in normative text (e.g. Section 9.2.1, MPI_GET_PROCESSOR_NAME), we should either replace it with more precise usage (as written, "name of the processor" should be specified as socket- or core-granularity, but clearly not node-level in ordinary 2021 usage) or replace it with "hardware node" where the more general usage is intended.

[wesbland]

At this point, I assume that this will not be making it into MPI 4.1. I'm going to move it to 5.0, but @puribangalore can move it back if he thinks its feasible for March.