2020 03 18

2020-03-18 meeting minutes

Attendees:

• Jeff Squyres
• Martin Rüefenacht
• Dan Holmes
• Tony Skjellum

COVID-19

Wow. It's real. Sucks.

Cache-refresh on pythonization.

Martin to work on fixing the conflicts in https://github.com/mpi-forum/mpi-standard/pull/132.

Embiggening

We looked for the errata that we want to file.

See https://github.com/mpiwg-large-count/large-count-issues/wiki/problems-possible-errata.

There's also a bunch of "to do" items -- logistics and mechanical stuff.

See https://github.com/mpiwg-large-count/large-count-issues/wiki/TODOs.

Tony suggests that we need to have someone look at the IO chapter to verify the embiggening. --> Tony sends email to Rajeev.

Re-iterating the rationale about all the confusion with datatype constructors:

In general, datatypes have three uses:

1. MPI_Aint used as number of bytes. You're using MPI_Aint simply as a large number.
2. MPI_Aint used as an absolute address. Then MPI_Aint is a bit string that represents a location in memory.
3. With MPI_Files, so you're potentially addressing something bigger than memory.

Bottom line: MPI doesn't necessarily know at construction/commit time whether you're in case 1 or case 2 because it depends on whether you use MPI_BOTTOM with the constructed datatype or not.

When embiggening:

1. Keep the old signature for backwards compat reasons (may be int, may be MPI_Aint, ... etc.)
2. If relevant, embiggen to MPI_Aint for use case 2 (i.e., absolute addresses)
3. If relevant, embiggen to MPI_Count for use case 3 (i.e., files)

Today, embiggening has only resulted in 2 bindings (cases 1 and 2 or cases 1 and 3). We have not (yet?) found a case where embiggening resulted in 3 bindings (cases 1, 2, and 3).