We could state that the output from get_info is implementation defined. With the caveat that a user must be able to pass the output from get_info to a subsequent communicator creation call and get back a communicator with the same behavior as the original one. On Mon, Oct 17, 2016 at 12:06 PM, Dan Holmes <[email protected]> wrote:

Hi Jim,

Another thought that occurred to me was getting rid of get_info - in favour of using the MPI_T interface to figure out what the MPI library has actually done. There is a well-defined semantic for MPI_T variables w.r.t. when can the value change, what variables exist, what do particular values of particular variables mean, etc.

We could propose to standardise some MPI_T variables, such as MPI_ANY_TAG_is_supported or MPI_ANY_TAG_is_permitted, to replace the get_info feedback mechanism.

Cheers, Dan.

On 17 Oct 2016, at 16:49, Jim Dinan <[email protected]> wrote:

Ahh crud, sorry I missed this meeting. I've got the next one on my calendar and should be there.

I was recently telling a colleague about this get_info stuff and he made a suggestion that initially sounded nuts, but is becoming more appealing. Can we just remove set_info? Many of the challenges we have are caused by this function, and yet its value is questionable. What do you think? Worth looking into?

~Jim.

On Fri, Oct 7, 2016 at 4:24 AM, Dan Holmes <[email protected]> wrote:

...

Hi all,

The next point-to-point teleconference will be on Monday 10th October 2016 at 11am Central US via webex.

Connection details are on the p2p wiki: https://github.com/mpiwg-p2p/p2p-issues/wiki

Agenda:

1) Deprecation of send cancel (issue #26): at the Sept 2016 meeting, Rolf correctly pointed out multiple additional administrative changes that are needed for this. I have a list of these changes and I am working through them. Once that is done, we will need 4 reviewers (Rolf + 3).

2) Communicator assertions (issue #11): at the Sept 2016 meeting, Pavan et al raised the valid objection that fixing the train-wreck of INFO_GET/SET may have knock-on effects on this and so we should delay the vote on it until we have the full picture.

3) Fixing INFO_GET/SET (issue #new): Jim and I have discussed a plan to get this moving.

Slides from Sept 2016 meeting with notes on discussion and way forward: https://docs.google.com/presentation/d/10EPCx2LuJ0BWCeUXIG3p XJjqQs1tlnlO-6TJXIC8G8Q/edit?usp=sharing

In addition to our next meeting (10th Oct), we will have 24th Oct and 7th Nov before 21st Nov, which is the 2-week deadline for the next face-to-face meeting.

Plan: Withdraw #11 from vote on 23rd Sept. [DONE] Create #new and produce a first draft of the text for the Standard. [IN PROGRESS] Discuss at the meeting on 10th Oct. Adjust text for the Standard and produce a first draft of the slides for presenting at the next face-to-face. Discuss at the meeting on 24th Oct. Find and fix all the references and stuff that's needed for a proper proposal (Rolf-proofing). Discuss at the meeting on 7th Nov. Final adjustments for #new, text, and slides. Announce #11 (1st vote) and #new (reading) to mpi-forum list by 21st Nov.

If we discover during the work on #new that #11 needs to be adjusted then we can re-start its formal procedure with a reading in December.

Cheers, Dan.

-- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: [email protected]

*Please consider the environment before printing this email.*

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

_______________________________________________ mpiwg-p2p mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p

_______________________________________________ mpiwg-p2p mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

_______________________________________________ mpiwg-p2p mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p

_______________________________________________ mpiwg-p2p mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p