2016 06 21

Catastrophic Errors

• The feedback from the forum was good and we are ready to move forward on it.

Error Handlers

• Rob suggestion: Let's go with option #3, but create a way to set a value on a communicator that causes the error handler not to be inherited from it's parent (or the other way around depending on preference).
• Aurelien: Let's split mpi-forum/mpi-issues#1 up into two issues where one has all the inheritance stuff and the other has everything else.
• Aurelien: Roll back the Chapter 2 changes entirely. The original example was fine and this has been a stumbling block.

ULFM

• Let's add the mpiexec flag.
• We need to answer Dan's question about initialization when using persistent communication.
• Ryan's MPI_COMM_FAILURE_ACK concern was that we'd be preventing hardware matching, but we think it's not an issue because matching can continue to be reported to the user because the errors are just "pending".
• Add the invalid output values fix as a separate issue.
• Roll back the DISCONNECT changes and create a separate issue.
• Create a branch from before the reading that we can use to track new things. Aurelien asserts that if we bring all the new changes as a separate issue, we can consider ULFM as read in its current form (all other changes are small enough).

Greenfield Error Handlers

• Let's add a way for the implementation to say whether or not it can long jump.
  • Possibly could add a way to have the implementation long jump for you?