feedback from face-to-face forum (reading) March 2019

[hppritcha]

notes from 3/19 forum reading of mpi-forum/mpi-standard#55

Dan notes there will be lots of conflicts with PR mpi-forum/mpi-standard#50. Examples of stuff rom chapters 8 and 12 being moved into chapter 10 in mpi-forum/mpi-standard#55. Considerable discussion about what chunks

HIGH PRIORITY ITEMS

• [x] pset name consistency? Dan thinks here it doesn't make sense. Others think yes. local op having "global" consistency. More than my process but outside the scope of MPI. We will add a set theory based blurb in text and also a venn diagram illustrating.

If two processes get the same process set name, then the intersection of the two sets is either the empty set or identical to the union of the two sets.

ITEMS WITH DEPENDENCIES OUTSIDE OF SESSIONS

• [x] errhandler argument of MPI_Session_init if ERROR_HANDLER NULL, rework in light of 55. Refer to issue: https://github.com/mpi-forum/mpi-issues/issues/102 (PR https://github.com/mpi-forum/mpi-standard/pull/50). On 6/24 webex, we decided to wait to get further insight from FT group about direction of PR 50.

LOWER PRIORITY ITEMS

- [ ] check line 33/34 on page 403 for squashing (unfortunately not sure what this is about now with so much text moved)

• [x] Add an advice to users about freeing/disconnecting. (This has to do verbiage around MPI_Session_finalize) - changed to advice to implementors.
• [x] correct C examples for pset_len now not needing the +1.

RESOLVED BY SPECIFYING THREAD SUPPORT LEVEL VIA INFO

• [x] Fortran MPI_FLAG_type discussion, want to be a 64 bit
• [x] back to why not moved MPI_Flags back into an info key - move this to being predefined info key, one info key defined with one of the four currently existing
• [x] Rolf complains about our big MPI_FLAG_THREAD_NONCONCURRENT_SINGLE, etc.

OTHER DONE ITEMS

This items have been addressed either in PR 55 or PRs open currently against PR 55.

• [x] perhaps move sections about MPI and threads in to chapter 10 or a subset thereof
• [x] should we reword the pset_len argument wording as well as in the info chapter. A shall not be bigger than - replace (it shall be at least one more than pset_len).
• [x] Aurelian asks about mixing requests from sessions with different thread levels of thread safety - we'll address this with a rationale section
• [x] in intro of chap 10 and in context chapter - When using the \emph{Peer to Peer Process Model} .. use instead When not using the \emph{World Process Model} ..
• [x] should we change name to MPI_Session_get_psetlen? or MPI_Pset_getlen?
• [x] line 211 or so in io chapter add a cross reference to peer to peer.
• [x] revert the removal of communicator group in io chapter.
• [x] MPI process usage in intro part of chap 10? Always use this.
• [x] add rationale about 10.4.0 for the MPI_TESTALL isolation business
• [x] need a minimum URI length for MPI_Comm_create_from_group
• [x] replace uri in MPI_Comm_create_from_group with a different name
• [x] need to update deficiencies with world process model in section 10.4 owing to changes from FT working group stuff - PR 50 above
• [x] Rich asks about issues with the compartmentalization approach
• [x] A single process (line 43) change to a single MPI process - actually reword to remove mention of process
• [x] check about info handle IN or INOUT? Should be INOUT for MPI_Session_init language neutral section.
• [x] MPI_Session_finalize - mention that handle is freed, and set to MPI_SESSION_NULL.
• [x] communication objects - replace with explicit list of communicators windows and files. - [ ] correct second example replacing MPI_Comm_free with MPI_Comm_disconnect
• [x] reword sentence with execution vehicles to remove this
• [x] fix IERROR NPSET_NAMES order and add a ',' in the
• [x] add constraints on the range of n.
• [x] fix character(LEN=len) for MPI_Session_get_nth_pset
• [x] MPI_Pset_get_info to replace MPI_Session_get_pset_info.
• [x] comma after pair must be defined size in the MPI_Session_get_pset_info.
• [x] MPI_comm_create_group - clarification to not mix MPI processes from two different "sessions", maybe an advice to users? Dan suggests using an example in 10.
• [x] mistake in F77 prototype for MPI_Session_get_pset_info. Maybe add a MPI_Pset_get_size. Jeff says to MPI_Pset_get_rank.
• [x] slightly adjust first example to avoid line overrun
• [x] number the examples
• [x] second example check return value of MPI_Session_init
• [x] change psetlen + 1 in call to MPI_Session_get_nth_pset
• [x] remove return code checking from second example. add some verbiage about not checking.
• [x] don't use info_val[MPI_MAX_INFO_VAL] in the second example
• [x] all MPI processes connected via the communicator. Keep the MPI_Comm_free but say something about using MPI_Comm_disconnect.
• [x] simplify fortran example, use errors abort
• [x] group constructors - drop sentence starting with "Except when creating groups from process sets..."
• [x] reformat MPI_INTERCOMM_CREATE_FROM_GROUPS definition
• [x] use MPI_INTERCOMM_CREATE and MPI_INTEROMM_CREATE_FROM GROUP usage to show up in index
• [x] MPI_INFO in section 10.4.2. mpitype and not mpifunc. also in 10.4.3.
• [x] clean up latex around MPI_SESSION_CREATE_KEYVAL (this is complicated)
• [X] Rolf doesn't like all the topology stuff and Dan removes it and the windows and the files stuff.
• [x] fix the foobars
• [x] 955 misspelled sesion.
• [x] local leader in local group for remote_group and remote_leader - add this even though not present for existing intercomm create function.
• [x] Martin thinks there are some phrases in the existing text for the World Process model that doesn’t quite fit the new world order. Specifically, some of the stuff about MPI being “active” in relation to initialised and finalised. I/we should read that section through to see what sticks out.
  • [x] Page 407, line 31: After MPI is initialized - still valid in Session World?
  • [x] Page 412, line 9: I assume we want to allow sessions to survive a finallize, correct?
  • [x] Page 412, line 47: Once MPI_FINALIZE returns, no MPI routine (not even MPI_INIT) may be called,
  • [x] Page 415, line 40++: Determining Whether MPI Is Active (which is then equated with MPI_INIT called)
• [x] Martin suggested that there might be a minimal change that we can do to make this proposal tools-friendly. Apparently, there is a place where we should add “session” as a thing that tools can do something with. Martin promised to send an email about that to give us an exact location and a suggested text change.
• [x] check errorhandler in line 594 in inquiry.tex
• [x] remove sentence on page 546 about MPI_QUERY_THREAD in line 13/14, say only okay to use if World process model is being used. Add something about MPI_IS_THREAD_MAIN that it also. Do we need such a function for sessions? May only support single and concurrent so we don't need to worry about funneled, etc.
• [x] see comments on inquiry.tex - replacing instantiation with initialization
• [x] add a figure for MPMD, and one with multi-architecture, something to break hierarchy, grey'd out example for what would be the return from MPI_Session_get_num_psets
• [x] process set names - add some text to go with the picture to describe in words what the figure is illustrating - some restrictions on how resources are assigned to a process set. consistency of membership.
• [x] Wesley mentions MPI_ERRORS_ABORT - we need to mention a blurb about using this with Sessions. Aurelian thinks this will only be local because all session ops are local. Dan says this is a scope concern. IMPORTANT
• [x] considerable discussion of our decision to use MPI_ERRORS_RETURN as default error handler. We should revisit this. 8.3 Error handling. (inquiry.tex)
• [x] Possibly rework when MPI_COMM_WORLD is valid/not valid in line 4 of page first discussing peer to peer model to cover when mixing world and peer to peer p. models
• [x] argument section 6.7.6 error class for invalid keyval
• [x] remove constraint about where pset_name and also replace process set with process set name in area around MPI_Group_from_session_pset
• [x] check wording just after MPI_Com_create_from_group - it needs to be changed.
• [x] The call is collective over the MPI processes contained in group - be consistent. Need to be more exact about group/uri tuple. Also may want to add a blurb about multi-threading case? Do we want to leave a gap and not specify collective over - since it matches comm_create_group.
• [x] reword sentence following the first example. Remember to change uri name if we decide to
• [x] Rolf asks about the MPI_TESTALL comment near the beginning of the Peer to Peer section. Connection with generalized requests? Need to investigate this. Say this can only be used with world process model.
• [x] discussion of error cases for MPI_Group_from_session_pset - when MPI_GROUP_NULL returned, session invalid. New error class(es)? - [ ] data type constructors/destructors thread safe - need a blurb about this. (This is a biggy - perhaps it can wait until clean-up in MPI-4.1?)
• [x] qualify MPI operations around MPI_Session_finalize better.
• [x] add other functions to thread safety list in EI chapter around line 633. Also add others like info, errorhandler, and datatype functions in this area.
• [x] clarify what number of psets returned from MPI_Session_get_num_psets means
• [x] Discussion of MPI_INFO_ENV - should this be usable if no active session - for now only allow in world model. Dan asks: can MPI_INFO_ENV be populated without access to argv? See issue:https://github.com/mpi-forum/mpi-issues/issues/115 (PR https://github.com/mpi-forum/mpi-standard/pull/110), which also punts on this change for the same reason.
• [x] need to fix ei chapter after we get the FT proposal in concerning default error handler (#102)
• [x] check lines 580-581 in io chapter that got zonked "The group is returned..."
• [x] discuss constant or variable number of pset names being returned over time (add this the function definition). lots of problems with shrinking, okay with growing. - [ ] discuss ability to exchange pset names to do things - not going to this in first proposal
• [x] some don't like the use of "caching" in this section.
• [x] AN MPI process, line 4 page 546.
• [x] question about how Sessions interacts with dynamic process model
• [x] questions about how a multithreaded app could create a comm for thread0 in mPI processes, etc.

[dholmes-epcc-ed-ac-uk]

We chose URI partly because it was different to TAG and partly because we had an idea that the string would be in uri format. Changing from URI to TAG (via FLAG), is good because it does not restrict to uri format (no longer intended), but bad because it is confusable with the integer tag parameters used elsewhere.

Can we name this parameter UNIQUE instead?

Suggested change \const{MPI_MAX_FROM_GROUP_TAG} \ \const{MPI_MAX_FROM_GROUP_UNIQUE} \

Elsewhere (for the MPI_COMM_CREATE_FROM_GROUP function only and plus/minus case-sensitivity) it means: s/TAG/UNIQUE/g

In text, it would mean usage like this (for example): The \mpiarg{unique} string uniquely identifies this operation ...