e.g. under "Software" on https://enccs.github.io/intermediate-mpi/
Doesn't look great but is hopefully easily fixable

• Collective operations with user-defined datatypes (basically how to define own MPI_Ops)
• Exercise: ?

Works locally though...

Since collectives are not a prereq, it would be better not to use one. We could have the pokemon-pack-unpack lesson start with only two ranks and simply MPI_Send the buffer to rank 1.

• Point-to-point modes: buffered, ready, synchronous, standard
• Point-to-point nonblocking
• Collective nonblocking
• Exercise: ?

include general info and installation instructions

so participants can copy-paste to catch up if needed
could be a collapsable box in the episode

this might already mostly be in place, but maybe make it even clearer:

• when should I be using this functionality?
• when should I not be using it?
• what are the possible pitfalls?

using e.g. https://shellshare.net/

good for participants to build a mental model

the Collective communication episodes probably don't require any prior knowledge of them. Shall we remove collectives from https://enccs.github.io/intermediate-mpi/#who-is-the-course-for?

Is there some standard format we can use with the Sphinx lesson?

had a discussion with Joachim who pointed out (as we knew) that derived datatypes and non-blocking parts overlap with the SNIC course. One topic not covered in the SNIC course is MPI-I/O, which would fit nicely into the intermediate level specification

• What RMA is and why it might be useful
• Windows, access functions, synchronization
• Exercise: maybe some quizzes?

We state that the lesson materials are CC-BY-4.0 in the text, which is good. However because we expect people to download and run the source files, that connection gets lost. We should copyright the source files by ENCCS, and state a license compatible with CC-BY-4.0.

Should we license that source code also CC-BY-4.0? Or e.g. MIT?

• Dos and Donts
• Exercise: ?

a nice option would be to have "Bonus" and "Superbonus" tabs like in the Message passing Pokémons exercise in https://enccs.github.io/intermediate-mpi/derived-datatypes/

from Joachim:

[...] looking into the example 2 of the block Extents and sizes, you directly feed the result of MPI_Get_address into the displacements of MPI_Type_create_struct.

To my understanding MPI_Get_address, returns the address with respect to MPI_BOTTOM, however the displacement needs to be specified with respect to the beginning of the derived data type you want to sent. So you need to subtract a (typically large offset).

For my own MPI course my teaching examples, in which I subtract the offset, work against OpenMPI. Please have a look and I am happy to discuss this - or be corrected in case my reading of the standard is wrong.

It renders correctly locally. There might be a problem with the GitHub action.

To consider

• Give less space to the communicators and groups episodes in favor of more in-depth treatment of datatypes.

To change

• Clarify the meaning of displacements in the typemap
• In the my_pair type-along, the addresses are relative to whatever MPI thinks is the first byte in memory. Make it so that they are relative to the first field in the data structure
• Clarify why/when to use pack/unpack and why/when to define datatypes.
  • The former can incur overhead, e.g. calls to functions in a dynamically linked library (-lmpi) are slower than calls to functions in your executable.
  • The latter is essential if we want to perform reductions with a custom operation.

To add

• Defining custom operations on custom datatypes. This could fit in the collective episode.
• Short discussion of whether it is possible to automatically generate the MPI representation of custom datatypes.
  • Automatic serialization/deserialization libraries (like Cereal for C++) but using these is not exactly the same as defining datatypes, e.g. you can't do custom reductions.
  • Introspection. Possible in C++ with metaprogramming, but do you really want to go there? 😄
  • Code generation. Build is in two passes then: first generate the code (the generation of the code needs some tool to analyze the AST) then compile it.

if participants of the December 2020 workshop are representative of the intended target audience also for future workshops, we might want to give more time to one-sided communication as that was the topic most were interested in

• Data representation in MPI with typemaps.
• Type constructors and life cycle of user-defined types.
• User-defined packing and unpacking.
• Exercise: ?

one question that came up about the exercise "Warm up your communicators and your groups" in Communicators and groups:

• what does this code do?

Might need some clarification on what it should do and how to know one is done

Day 1:

• The hint /* FIXME define the data for the move in the game */ could be made more clear. Use “initialize” instead of “define”. I assumed it was to define new derived datatypes.
• For me making a reference to Pokemon made the exercises go out of context.

Day 2:

• Choose a linear color gradient for the All-to-all visual
• Add FIXME in the exercise scaffolds so that editors highlight it.
• Maybe go deeper into the halos/border problem. Or a N-body problem for classical Molecular Dynamics and show the advantage of using non-blocking.

Day 3:

• The visuals in third episode (synchronization) could be improved with some arrow heads. Also, the lines in the visuals have new colours (red, green & purple) which is different from the previous two episodes (red and blue).

• Pros and cons of combining MPI and multithreading
• Exercise: ?

• Active synchronization
• Passive synchronization
• Exercise: ?

• Describe what communicators are and why it might be useful to have more than one.
• Exercise: computing pi with Monte Carlo.

in https://enccs.github.io/intermediate-mpi/one-sided-concepts/

• which exercises are best done in breakout rooms where learners solve it themselves and ask questions to room helper
• which exercises can be demonstrated by type-along in the main session
• recommend to use a shared workshop document for questions and answers

It seems literalinclude doesn't work with the Sphinx RTD theme. What a headache!

in first instance under https://enccs.github.io/intermediate-mpi/derived-datatypes/#representation-of-datatypes-in-mpi

To have a more detailed trace of how we scheduled the first iteration of the workshop.

I had some questions on the meaning and use of the target_disp parameter in the RMA functions. For the next iteration:

• Add figure(s) to explain how these functions compute the address on the target process using information known to the window object (disp_unit)
• Add example(s) (they could be exercises) that require more thinking as to what should be passed for these parameters.