2020 03 25

2020-03-25 meeting minutes

Attendees:

• Jeff Squyres
• Martin Rüefenacht
• Dan Holmes
• Tony Skjellum
• Puri Bangalore
• Derek Schafer

A New Big Effort

1. Dan suggests that we might want to systematically review all the LIS and tighten up the language.

   • Suggestion: let's charge the chapter committees to do this.
   • Let's give direction to the chapter committees:
     • Give them ~3 examples per chapter
     • Give some guidelines about what to do (and what not to do)

2. Should we re-format how the LIS are displayed? E.g., turn into bulleted list in the main text?

   • The advantage would be to have a lengthier description of each argument
   • Could also just have "short" description (rendered in the LIS) and a "long" description (rendered in a list in the main text). Easy to do with Python.
   • Maybe even the "long" description is optional, because not all params need a lengthy description...? (or if the "long" is not supplied, just repeat the "short" param)

   A. Should we also have a 1-3 sentence description of the procedure as part of the python as well? - Can have a beauty contest on how to render it (above, below, etc.).

   --> We (embiggening WG) should not take on this work. We should mock up a few examples and some sample renderings, and ask the Forum: do we want to do this? If so, the bulk of the work should come down to the chapter committees.

   B. Rolf's Big Table about the properties of each procedure (from all the Semantic Terms work) should also be captured in the Python. - This would make his Big Table be able to be generated automatically. - Martin R. says "Yes, this, and Much Much more!" - Dan points out: this would make proposals for new APIs be much, much precise. HUZZAH!! - Dan thinks that this is simpler than 2A (!). - Martin has (at least the beginnings of) this in a branch - Take this work over the Semantic Terms WG? - Dan does say that there is a bunch of stuff we know about each procedure, but there's probably things we don't (yet) know/haven't (yet) categorized. - Definitely: give this to the Semantics Terms WG

   • An idea: have a formal mechanism for "exceptions"

     • Because lots of MPI-1/2/3 concepts are not "pure" -- they didn't really fit into the real rule/concepts that excepted. Look at the Semantics terms and all of its exceptions on https://github.com/mpi-forum/mpi-issues/issues/96.
     • So have a formal mechanism in the Python specification for exceptions.
     • E.g., this procedure is XYZ... with this formal exception (because it doesn't 100% fit the formal rule/specification/whatever).
     • Then we can disallow the any exceptions for any future procedure/operation specifications (e.g., MPI-4.x/5.0 and beyond).

   • There's some gigantic implications here:

     • Whole-document CI: it can analyze the entire document and see if there are any inconsistencies on a given PR. "This PR proposes something that causes inconsistencies with ...XYZ..."
     • Automatically generate the ChangeLog 😄
     • Do a (retrospective) analysis to see what the semantic changes were between MPI vX and MPI vY.

   • The key here would seem to be to get Rolf on board with this.

     • He would be excellent at exactly this kind of stuff.

Discussion about git merging of Pythonization PR

• Jeff looked at this
• Try to rebase feat-modern-lang-bindings to HEAD of mpi-4.x
• Much rebased cleanly. But got a bunch of conflicts with changes from Bill Gropp. Specifically, his changes to the bindings.
• You get conflicts like this:

>>>>>>
A. Binding with Bill's changes
======
B. Original binding
======
C. Our Pythonized binding
<<<<<<

You have to compare A and B and see what the change was that Bill made. And then see if it's relevant to apply that change to C.

Jeff suggests writing a routine to compare A and B, because sometimes the changes are small / hard for a human eye to see.

Martin will have a look at this.

Discussion about Pythonization of Semantic Terms PR

• What things do we know already? (from the table on https://github.com/mpi-forum/mpi-issues/issues/96)
• How do we want to express that in Python?
• Much work will explode from this (e.g., 2nd and 3rd order effects)
• Take a first cut of this back to the Semantic Terms WG
• Once you have a final plan, Unleash The Rolf on it.

...much discussion/Jeff didn't capture it. Dan? Martin? Puri?...

Future work:

0. See the above items:
   • Addition of "long" descriptions for MPI procedure params
   • Addition of MPI procedure descriptions in Python
   • Capturing of lots of param/procedure properties in Python (e.g., render Rolf's giant Semantics Terms table automatically) --> This is work for the Semantics Terms WG
1. Making official machine-readable file(s) from Python to publish on mpi-forum.org
   • Python?
   • JSON?
   • mpi.h / mpif.h / mpi module / mpi_f08 module
   • ...?
2. Continuous integration with Pythonization
   • Pytest
   • Generate a list of changed / added / deleted bindings per PR
   • ...
3. All the "to do" items (see https://github.com/mpiwg-large-count/large-count-issues/wiki/TODOs)
4. MPI-5 things -- all-new language stuff (C++, divorce 1:1 relationship to C bindings, ...etc.)
   • Remember: there are several people who want to be involved in these discussions (e.g., Jeff H., Lisandro D., ...etc.).

Additional future-work actions (arising from addendum discussion at the end of the call)

1. [@Martin Rüfenacht] parse Rolf’s table.
2. [@Purushotham Bangalore] and [@Dan Holmes] parse LemonSpotter-related Python stuff from the Slack channel.
3. [All Three] Think hard; post questions and suggestions to private 3-way Slack discussion.
4. [@Purushotham Bangalore] convene a meeting of the Semantic Terms WG - topic: deeper insights, more stages.