[Mpi-forum] PR 540 -- I/O chapter fixes (started)

[Skjellum, Anthony via mpi-forum]

All: This PR reflects discussions (so far) on PR 455 and PR 425.

https://github.com/mpi-forum/mpi-standard/pull/540

It will continue to be updated as we work through the rest of the discussion 
tomorrow.

I will be able to make the fixes as we go (I hope) through the rest of the PR 
425 and 455 issues tomorrow.

Any further points appreciated.

Tony




Anthony Skjellum, PhD

Professor of Computer Science and Chair of Excellence

Director, SimCenter

University of Tennessee at Chattanooga (UTC)

tony-skjel...@utc.edu  [or skjel...@gmail.com]

cell: 205-807-4968

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan

[Wesley Bland via mpi-forum]

It seems like Martin covered all of the points I was going to mention. I’d 
summarize by saying that I believe we’re following the rules as written. I also 
believe that we’re giving the rules a bit of abuse here because of the volume 
of changes coming in at the last minute.

That being said, I think the volume of changes is actually a good thing. This 
is the first time we’re ratifying the MPI Standard since moving from SVN to 
Git/GitHub and doing so has made the process more transparent and easier for 
people to catch these sorts of small issues that we’re discussing now. All of 
being at home has potentially also given us more time over the last few months 
to find each of these issues.

I freely expect and admit that I’ve probably missed a PR or two as I’ve been 
trying to keep up. Hopefully we’ve found them all now (thanks to those who have 
pointed me to some of those that I missed).

If we do end up having another FRM, I agree that it gives us one more 
opportunity to give the entire document a read-through. I don’t think we’ll do 
another pass like we did before the December meeting, but we should certainly 
have the CCs look through it. However, when doing so, remember that we’ll have 
to accept some level of imperfection. The document has been imperfect for a 
long time and will continue to be so in the future. We have to look at the list 
of issues that we know about and decide which ones we can live with and for 
which ones we’re willing to delay publishing MPI 4.0. It’s especially important 
to be cognizant of the procedures that we’ve chosen for ourselves when doing 
this and to avoid making more and more exceptions just to get “one more thing” 
into the document. Every time someone suggests that we should “just make this 
change" to improve the text, you should think “just make this change” == “delay 
MPI 4.0 for another meeting or more”.

Thanks,
Wes

> On Feb 23, 2021, at 4:30 AM, Martin Schulz via mpi-forum 
> mailto:mpi-forum@lists.mpi-forum.org>> wrote:
> 
> Hi Rolf,
> 
> Comments inline marked with ">>"
> 
> Martin
> 
> 
> -- 
> Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems
> Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching
> Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)
> Email: schu...@in.tum.de 
> 
> 
> 
> On 23.02.21, 09:53, "mpi-forum on behalf of Rolf Rabenseifner via mpi-forum" 
>   on behalf of 
> mpi-forum@lists.mpi-forum.org > wrote:
> 
>Dear Wesley and all,
> 
>Wesley, you did yesterday a wonderful job. 
>Please do not take the following items as any critism on your work.
>they are only on procedural/general problems we may have.
> 
>1. Can it be that one No-No-vote can influence the outcome of the MPI 
>   standard when the majority does not see a problem with the text?  
> 
>>> Yes, that is correct - if a No-No fails, then we vote on whether to advance 
>>> the standard without that PR.
> 
>   We may procedurally gave and still give no-no-voters to much 
>   influence on the text.
> 
>>> To some degree, yes, but this is supposed to be a last stop-gap measure and 
>>> then we do, of course, folks to act reasonable with the consequences, which 
>>> - so far - has worked IHMO.
> 
>   I hope that this 
>- will not happen during this meeting
> 
>>> To be honest, I wouldn't be surprised if it did, and probably not without 
>>> reason.
> 
>- and if it happens then I hope that the FRM is changed to a RC
> 
>>> That's why we will have that vote on a different day - when we vote on the 
>>> whole standard, everyone will have seen what had been voted in and what out 
>>> and has the ability to vote accordingly. Personally, I hope as well that, 
>>> if we find problems and we reject additions that are impactful, that a 
>>> majority would vote for another round for the FRM.
> 
>- and therefore the exactly same PR is then voted with a normal
>  erata-vote into the standard on the next meeting.
> 
>>> That is technically correct, but I would hope that we can fix issue that 
>>> are brought up so that the concerns of the few no/no votes are met after 
>>> the changes. Note that we do not have to fix them this week (would be good 
>>> if we do, but not required), but we need to add them to the list of fixes 
>>> needed. So far, from the issues that are noted on the list, I would think 
>>> that we can achieve agreement on all of them before June. We'll see - I am 
>>> an eternal optimist __.
> 
> 
>2. My aplogies that -- also I was prepared to catch it --
>   I oversaw the moment when the folowing text change was presented:
> 
>   RC 1
> Example 5.22 An elaborate example.
> int position, i;
> float a[1000];
> char buff[1000];
>   changed in RC 2
> Example 5.22 An elaborat

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan

[Martin Schulz via mpi-forum]

Hi Rolf,

Comments inline marked with ">>"

Martin


-- 
Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems
Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching
Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)
Email: schu...@in.tum.de
 
 

On 23.02.21, 09:53, "mpi-forum on behalf of Rolf Rabenseifner via mpi-forum" 
 wrote:

Dear Wesley and all,

Wesley, you did yesterday a wonderful job. 
Please do not take the following items as any critism on your work.
they are only on procedural/general problems we may have.

1. Can it be that one No-No-vote can influence the outcome of the MPI 
   standard when the majority does not see a problem with the text?  

>> Yes, that is correct - if a No-No fails, then we vote on whether to advance 
>> the standard without that PR.

   We may procedurally gave and still give no-no-voters to much 
   influence on the text.

>> To some degree, yes, but this is supposed to be a last stop-gap measure and 
>> then we do, of course, folks to act reasonable with the consequences, which 
>> - so far - has worked IHMO.

   I hope that this 
- will not happen during this meeting

>> To be honest, I wouldn't be surprised if it did, and probably not without 
>> reason.

- and if it happens then I hope that the FRM is changed to a RC

>> That's why we will have that vote on a different day - when we vote on the 
>> whole standard, everyone will have seen what had been voted in and what out 
>> and has the ability to vote accordingly. Personally, I hope as well that, if 
>> we find problems and we reject additions that are impactful, that a majority 
>> would vote for another round for the FRM.

- and therefore the exactly same PR is then voted with a normal
  erata-vote into the standard on the next meeting.

>> That is technically correct, but I would hope that we can fix issue that are 
>> brought up so that the concerns of the few no/no votes are met after the 
>> changes. Note that we do not have to fix them this week (would be good if we 
>> do, but not required), but we need to add them to the list of fixes needed. 
>> So far, from the issues that are noted on the list, I would think that we 
>> can achieve agreement on all of them before June. We'll see - I am an 
>> eternal optimist __.


2. My aplogies that -- also I was prepared to catch it --
   I oversaw the moment when the folowing text change was presented:

   RC 1
 Example 5.22 An elaborate example.
 int position, i;
 float a[1000];
 char buff[1000];
   changed in RC 2
 Example 5.22 An elaborate example.
 int position, i = 200;
   Correct 
 float a[200];
   Correct
 char buff[1000]; /* larger than sizeof(int) + 200 * sizeof(float) */
   Wrong: This sentence should present a sufficient requirement and
  not only a maybe necessary requirement (like large than 0) 
   Correct would have been:
"larger than the sum of the sizes returned from MPI_PACK_SIZE
 for 1 MPI_INT and 200 MPI_FLOAT"

>> Thanks for bringing this up, I added this to the agenda for today

2a. The procedural problem is that the presentation of changed files
may be swammed by minor corrections like typos, grammer, formatting,
removed hyphens, index entries, corrections of macro usage, ...
The real text changes may be overseen.


3. Especially for the point-to-point chapter this is really hard.

   May be also for other chapter as seen in item 2. above.

   How to proceed with this problem?

   (Of course without loosing time on irrelevant changes.)

>> Not sure there is a good way - perhaps we should adjust how we handle this 
>> in the future by recommending to bundle only "like" changes in a single PR 
>> (only index, only grammar, ...), but for now this is too late. I think we 
>> have to rely on everyone looking through the PR and I would also like to see 
>> CC chairs to go over their chapter again, especially if we push the FRM by 
>> one meeting.


4. It is overseen, if reviews for RC 1 are partially overseen
   (or just not implemented).

   https://github.com/mpi-forum/mpi-issues/issues/341
   is full of change requests. 
   Only partially these requests have check boxes, partally not.
   And only partially, these check boxes are checked.

   The issue #341 was quietly moved on Jan 19 from 4.0 to 4.1.

   Are there other chapter with outstanding corrections?

   Can we fix it without no-no-votes by reading the required changes
   during this meeting and having them as errata votes next meeting?

   How to proceed with this problem?

>> We did indeed move some items, which were not deemed ready nor critical, to 
>> MPI 4.1 (typically as part of one of the virtual meetings, no

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan

[Rolf Rabenseifner via mpi-forum]

Dear Wesley and all,

Wesley, you did yesterday a wonderful job. 
Please do not take the following items as any critism on your work.
they are only on procedural/general problems we may have.

1. Can it be that one No-No-vote can influence the outcome of the MPI 
   standard when the majority does not see a problem with the text?  

   We may procedurally gave and still give no-no-voters to much 
   influence on the text.

   I hope that this 
- will not happen during this meeting
- and if it happens then I hope that the FRM is changed to a RC
- and therefore the exactly same PR is then voted with a normal
  erata-vote into the standard on the next meeting.


2. My aplogies that -- also I was prepared to catch it --
   I oversaw the moment when the folowing text change was presented:

   RC 1
 Example 5.22 An elaborate example.
 int position, i;
 float a[1000];
 char buff[1000];
   changed in RC 2
 Example 5.22 An elaborate example.
 int position, i = 200;
   Correct 
 float a[200];
   Correct
 char buff[1000]; /* larger than sizeof(int) + 200 * sizeof(float) */
   Wrong: This sentence should present a sufficient requirement and
  not only a maybe necessary requirement (like large than 0) 
   Correct would have been:
"larger than the sum of the sizes returned from MPI_PACK_SIZE
 for 1 MPI_INT and 200 MPI_FLOAT"

2a. The procedural problem is that the presentation of changed files
may be swammed by minor corrections like typos, grammer, formatting,
removed hyphens, index entries, corrections of macro usage, ...
The real text changes may be overseen.


3. Especially for the point-to-point chapter this is really hard.

   May be also for other chapter as seen in item 2. above.

   How to proceed with this problem?

   (Of course without loosing time on irrelevant changes.)


4. It is overseen, if reviews for RC 1 are partially overseen
   (or just not implemented).

   https://github.com/mpi-forum/mpi-issues/issues/341
   is full of change requests. 
   Only partially these requests have check boxes, partally not.
   And only partially, these check boxes are checked.

   The issue #341 was quietly moved on Jan 19 from 4.0 to 4.1.

   Are there other chapter with outstanding corrections?

   Can we fix it without no-no-votes by reading the required changes
   during this meeting and having them as errata votes next meeting?

   How to proceed with this problem?


5. Did we oversaw other PRs (like the very old number PR425 
   merged very late)?

Best regards
Rolf


   
  
- Original Message -
> From: "Main MPI Forum mailing list" 
> To: "Main MPI Forum mailing list" 
> Cc: "Wesley Bland" 
> Sent: Thursday, February 18, 2021 8:58:55 PM
> Subject: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan

> Hi all,
> 
> I wanted to give an update on the plan for the meeting next week after our
> virtual meeting yesterday.
> 
> The original plan for the Feb 2021 meeting was to be a Final Ratification
> Meeting (FRM), which would mean that at some point during the meeting, we 
> would
> potentially ratify MPI 4.0 and elect officers for the next release of the MPI
> Standard. The rules for that are in our procedures document on our website and
> it turns out they handle our current situation very well. The relevant pieces
> are this:
> 
> 
> 
>1. At the last meeting, we made two lists of items that were not yet fixed.
>These lists are maintained on agenda and voting page for the meeting: [
>https://www.mpi-forum.org/meetings/2021/02/votes |
>https://www.mpi-forum.org/meetings/2021/02/votes ]
>2.
>1. The items that we knew about by the end of the December 2020 
> meeting -
>Everything on this list that was fixed will be voted on using the same 
> rules as
>an errata vote .
>2. The items that were discovered after the end of the December 2020 
> meeting -
>Everything on this list that was fixed will be voted on using the same 
> rules as
>a no-no vote .
>3. We will construct another list during the February 2021 meeting to keep 
> track
>of remaining issues that we see with the document. This list is in the same
>place as where we tracked the previous work: [
>https://github.com/mpi-forum/mpi-issues/projects/2 |
>https://github.com/mpi-forum/mpi-issues/projects/2 ]
>4. On a separate day from the items in #1 above, we will have a ballot to 
> decide
>whether the remaining issues should cause us to delay ratifying MPI 4.0.
>5.
>1. Without attempting to editorialize too much (people may vote in 
> whatever way
>they think is most appropriate), based on the conversations in the 
> virtual
>meeting yesterday, I would expect this ballot to pass. The 
> ramifications of
>that are below.
>6. If the ballot in #3 fails (saying the list of remaining items is not 
> blocking
>MPI 4.0), then we h