2020 04 01

2020-04-01 meeting minutes

Attendees:

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

Discussion about git merging of Pythonization PR

Jeff and Martin worked out Martin's git weirdness yesterday.
Martin is working on getting the MacOS git merge tool to help examine the diff between Bill's changed binding and the original binding (to determine whether we need to update our Python).
There's only 19 instances of this, so it's not a lot of work on this.
Martin is continuing to work on this; should be done in a day or so.

Adding properties to Pythonization (semantic terms)

Since the last meeting...

Dan + Martin took a first attempt at adding attributes to the Pythonized bindings (e.g., local vs. non-local).

This becomes more complex when you try to do this more orthogonally: e.g., can we do blocking vs. non-blocking? The problem is that these terms are really compound definitions. E.g., non-local includes elements of whether the operation is collective, ... etc.

This is not as simple as we think it is. :gasp:

Yes, we still want to capture these things in the Pythonized bindings (and potentially auto-generate the table in the back that Rolf et al. are proposing in the semantic terms PR). But we don't yet know how to express this. This is going to take a lot more thought.

Here's some examples from Dan from slack:

nonblocking = local or incomplete
 so ( local => nonblocking ) = true
 but ( nonblocking => local ) = false
 and ( incomplete => nonblocking ) = true
 but ( nonblocking => incomplete ) = false

So we really might need a full predicate logic description of these kinds of things.

...this is work for the semantic terms group to continue.

...that being said, we should probably have some discussions here first before bringing this to the larger semantic terms group. E.g.:

Design a syntax that only correct definitions are expressible.
Design a syntax that some kind of automated check will show problems.

Item 2 seems more flexible, and/or gives us flexibility for the future. We're also not confident that it is possible to do item 1, especially given that we know we have incomplete knowledge and/or it may (will?) change over time.

Minor beauty contest:

single function for each attribute?
attributes?
...?

Perhaps something like this:

1.
\begin{mpi-binding}
     function_name("MPI_Finalize", properties=(Operation.COLLECTIVE, Locality.NON_LOCAL))
 \end{mpi-binding} 

1.5:
\begin{mpi-binding}
     function_name("MPI_Finalize")
    properties(Operation.COLLECTIVE, Locality.NON_LOCAL)

    # Maybe this, if it can be both of these states?
    properties(Operation.COLLECTIVE, Locality.NON_LOCAL, Locality.LOCAL)

    # Or:
    properties(Operation.COLLECTIVE, Locality.CONDITIONAL)

    # Or -- this one requires calling all the parameter() invocations first:
    properties(Operation.COLLECTIVE,
        Locality.NON_LOCAL if parameters.output.flag==True else Locality.LOCAL)

    # Or:
    properties_set(Operation.COLLECTIVE, foo, bar, ...)
    if parameters.output.flag == True:
        properties_add(Locality.NON_LOCAL)
    else:
        properties_add(Locality.LOCAL)
    # ^^^ We kinda seem to like this set of ideas the best.

    # Another orthogonal+useful idea:
    # Somehow denote which version(s) of MPI this applies to (e.g., since MPI 3.1)

 \end{mpi-binding} 

# Need some kind of syntax to express conditional properties.
# E.g., the properties of MPI_TEST depends on whether the flag returns TRUE or FALSE.

2.
\begin{mpi-binding}
    function_name("MPI_Finalize")
    function_property(Collectiveness.WeakBlocking)
    function_property(Locality.nonlocal)
    operation_property(Collective.CollectiveOperation)
\end{mpi-binding}

3.
\begin{mpi-binding}
    function_name("MPI_Finalize")
    function_collectiveness(FunctionProperty.WeakBlockingCollective)
    function_locality(FunctionProperty.Nonlocal)
    operation_collectiveness(OperationProperty.Collective)
\end{mpi-binding}

4.
\begin{mpi-binding}
    function_name("MPI_Finalize")
    property(FunctionProperty.WeakBlockingCollective)
    property(FunctionProperty.Nonlocal)
    property(OperationProperty.Collective)
\end{mpi-binding}

Kept all the above to record the options we iteratively talked through.

Here was the winner (i.e., these ideas -- the implementation specifics may end up looking a little different):

\begin{mpi-binding}
     function_name("MPI_Finalize")

    # Then invoke all the parameter() calls (for this example -- MPI_Finalize --
    # yes, this is meaningless, but I'm just being explicit here for purpose of
    # explanation in the notes)
    parameter(...)
    parameter(...)
    parameter(...)

    # Then use one or more functions to define the properties for this function
    properties_set(Operation.COLLECTIVE[, foo, bar, ...])
    if parameters.output.flag == True:
        properties_add(Locality.NON_LOCAL)
    else:
        properties_add(Locality.LOCAL)
 \end{mpi-binding}

Also, it would be great to render these properties in the LaTeX / PDF somehow, too -- right at the point of rendering of the function itself (i.e., not just include this information in the semantic terms table at the end of the spec, ...etc.).

Next step is to come up with the model:

This will definitely require more thought (per above -- some of the ones we know today are really compound terms).

Once we have the model:

Come up with the Python keywords to represent the elements of the model
Code up the error checker (to check if an individual function definition is correct or not)

Open question:

Should we have a properties_exception() function?
- I.e., "we know this violates the model, but we allow it anyway"
- Will be useful for functions that were already defined -- i.e., allow behavior that was previously defined that we didn't realize violates the model
- We can disallow it for new MPI functions (e.g., MPI-5 and beyond)

Next steps

Martin/Jeff

Finish the Pythonization PR

Puri/Dan:

Define version 1 of the model.
Start with the stuff that Dan typed in Slack (he'll put it here on the wiki).

Provide feedback

Saved searches