<div dir="ltr">Rolf,<div><br></div><div>Could you provide a list of the specific changes that you feel are needed on these tickets? For reference, and to bring in feedback from others on the cc, we are discussing:</div><div>
<br></div><div>MPI_Aint_add -- <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349</a></div><div>Linked list example updates -- <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402</a></div>
<div>MPI_Aint_diff -- <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404</a></div><div><br></div><div>Let's solve the technical issues first to see where things stand, and then come back to the issue of how to handle voting on these changes.</div>
<div><br></div><div>Thank you for helping to improve these tickets!</div><div><br></div><div>Best,</div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner <span dir="ltr"><<a href="mailto:rabenseifner@hlrs.de" target="_blank">rabenseifner@hlrs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Jim,<br>
<br>
I would like to disagree.<br>
Looking at #349, I see wording like "base address" etc.<br>
whereas MPI-3.0 p102.29 uses "absolute address".<br>
<br>
And, the ticket does not show the location of the new text,<br>
nor all the needed background info.<br>
<br>
MPI is a standard document and the proposed change<br>
(absolute addresses can no longer be used in<br>
normal arithmetic) should be well prepared.<br>
<br>
The current text is not ready.<br>
<br>
You start to differentiate between "absolute addresses"<br>
and "relative displacements" and their use of MPI_Aint.<br>
<br>
Please have a look at 2.5.6 on page 16.<br>
This section should be clarified.<br>
<br>
Please try to produce one proposal that is complete<br>
and fits to the standard.<br>
Voting in small pieces (several tickets) is not the best.<br>
<div class="im HOEnZb"><br>
Best regards<br>
Rolf<br>
<br>
----- Original Message -----<br>
> From: "Jim Dinan" <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>><br>
> To: "Rolf Rabenseifner" <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>><br>
> Cc: "MPI-WG Fortran working group" <<a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a>>, "longb" <<a href="mailto:longb@cray.com">longb@cray.com</a>>, "Jim Dinan"<br>
> <<a href="mailto:dinan@mcs.anl.gov">dinan@mcs.anl.gov</a>><br>
</div><div class="HOEnZb"><div class="h5">> Sent: Thursday, December 12, 2013 5:51:30 PM<br>
> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question<br>
><br>
><br>
> Hi Rolf,<br>
><br>
><br>
> Thanks for the corrections -- I apologize, what I had sent was a very<br>
> rough draft of the proposal. I applied your changes to the<br>
> proposal, cleaned some things up, and added the datatypes examples<br>
> corrections. Could you take another look when you get a chance?<br>
><br>
><br>
> In terms of proposal logistics, I would like to let MPI_Aint add and<br>
> diff tickets progress independently. I agree that they need to be<br>
> together, and I think we can rely on the chapter committee to handle<br>
> that if add/diff end up split between two versions of the standard.<br>
> MPI_Aint_diff should be ready for a reading at the next meeting and<br>
> MPI_Aint_add will be ready for a first vote. Given the discussion<br>
> about MPI 3.x/4.0 timeline yesterday, I think the risk of these not<br>
> being in the same release of the spec is very low. Since the Forum<br>
> has already done all of the work required to move MPI_Aint_add to a<br>
> vote, I would prefer not to rewind this process by merging it with<br>
> the diff ticket.<br>
><br>
><br>
> ~Jim.<br>
><br>
><br>
><br>
> On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner <<br>
> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
><br>
><br>
> Jim and all,<br>
><br>
> MPI_Get_address((char *) addr1 - (char *) addr2, &result)<br>
><br>
> This is really wrong, because (char *) addr1 - (char *) addr2<br>
> is not an address and cannot be used as input to MPI_Get_address.<br>
><br>
> (char *) addr1 - (char *) addr2 is a displacement.<br>
><br>
> Both tickets 349 and 404 need to be together, because they<br>
> are based on a clear distinguishing between<br>
> - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y<br>
> - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x,<br>
> addr_y<br>
> - relative displacements (diff of two absolute addresses), e.g.<br>
> dist_xy<br>
><br>
> Your new statement is that calculations like<br>
> dist_xy = addr_y - addr_x<br>
> addr_y = addr_x + dist_xy<br>
> need to be done by subroutine calls or functions,<br>
> because absolute addresses are stored in MPI_Aint variables<br>
> through some (unknown/strange) mapping,<br>
> wheras relative displacements are normal unsigned integers<br>
> that can be used for normal arithmetic.<br>
><br>
> The one ticket must show this clearly and must be integrated into<br>
> section 4.1.5<br>
><br>
><br>
> Best regards<br>
> Rolf<br>
><br>
><br>
> ----- Original Message -----<br>
><br>
><br>
> > From: "Jim Dinan" < <a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a> ><br>
> > To: "Rolf Rabenseifner" < <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> ><br>
> > Cc: "MPI-WG Fortran working group" <<br>
> > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a> >, "longb" < <a href="mailto:longb@cray.com">longb@cray.com</a> >,<br>
> > "Jim Dinan"<br>
> > < <a href="mailto:dinan@mcs.anl.gov">dinan@mcs.anl.gov</a> ><br>
> > Sent: Thursday, December 12, 2013 3:20:41 PM<br>
> > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question<br>
> ><br>
> ><br>
> > Hi Rolf,<br>
> ><br>
> ><br>
> > Thank you very much for the feedback! Sorry if I forgot to<br>
> > respond;<br>
> > the comments definitely were not ignored. We discussed the Aint<br>
> > difference calculation in the working group and decided to create<br>
> > an<br>
> > additional ticket for MPI_Aint_disp. We did not see a clean way to<br>
> > handle this in MPI_Aint_add, because both arguments need to be<br>
> > handled as unsigned in the arithmetic.<br>
> ><br>
> ><br>
> > <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404</a><br>
> ><br>
> ><br>
> ><br>
> > I have a list of fixes the to the datatypes examples that I'll post<br>
> > to the ticket soon.<br>
> ><br>
> ><br>
> > Jeff Squyres is also helping us move the MPI_Aint arithmetic<br>
> > routines<br>
> > to functions in the Fortran bindings. Should be done today.<br>
> ><br>
> ><br>
> > Were there any other concerns that we missed?<br>
> ><br>
> ><br>
> > Thanks,<br>
> > ~Jim.<br>
> ><br>
> ><br>
> ><br>
> > On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner <<br>
> > <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
> ><br>
> ><br>
> > Jeff and Bill,<br>
> ><br>
> > <<br>
> > <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22</a><br>
> > ><br>
> > was ignored.<br>
> > The answer seems to be yes and the clear implication is that<br>
> > we need also a routine to calculate disp := addr2-addr1<br>
> ><br>
> > About the Fortran Interfaces:<br>
> > We should keep the old style without INTENT, because for the<br>
> > old-style<br>
> > the implementor has the freedom to add INTENT as he/she wants<br>
> > and it is still compliant with the outcome of the definition.<br>
> ><br>
> > I do not see, why we have a function in C and a subroutine<br>
> > in Fortran.<br>
> > Like MPI_Wtime, in all three languages (C, new and old Fortran),<br>
> > we should do the same.<br>
> ><br>
> > Best regards<br>
> > Rolf<br>
> ><br>
> > ----- Original Message -----<br>
> > > From: "Jeff Squyres (jsquyres)" < <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a> ><br>
> > > To: "< <a href="mailto:longb@cray.com">longb@cray.com</a> >" < <a href="mailto:longb@cray.com">longb@cray.com</a> >, "MPI-WG Fortran<br>
> > > working group" < <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a> ><br>
> > > Sent: Thursday, December 12, 2013 12:17:40 AM<br>
> > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question<br>
> > ><br>
> > > Sounds good to me.<br>
> > ><br>
> > > Rolf -- is there any MPI reason we would not want to do this?<br>
> > ><br>
> > ><br>
> > > On Dec 11, 2013, at 4:41 PM, Bill Long < <a href="mailto:longb@cray.com">longb@cray.com</a> > wrote:<br>
> > ><br>
> > > ><br>
> > > ><br>
> > > > On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote:<br>
> > > >> This ticket got a formal reading today at the Forum:<br>
> > > >><br>
> > > >> <a href="http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349" target="_blank">http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349</a><br>
> > > >> (as of this writing, there's still a BIND(C) in there, but<br>
> > > >> it<br>
> > > >> will be removed shortly)<br>
> > > >><br>
> > > >> The function is basically intended to perform a mathematical<br>
> > > >> operation. As such, I think that the 2 Fortran bindings<br>
> > > >> should<br>
> > > >> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME).<br>
> > > >><br>
> > > >> Do you agree? If so, the ticket author (Jim Dinan) is<br>
> > > >> amenable<br>
> > > >> to<br>
> > > >> changing the Fortran bindings to the following (and I'm<br>
> > > >> assuming<br>
> > > >> I have the syntax below correct, but feel free to correct me<br>
> > > >> if<br>
> > > >> they're wrong):<br>
> > > >><br>
> > > ><br>
> > > > Certainly it makes more sense for these to be functions in<br>
> > > > Fortran.<br>
> > > > Particularly if the programmer prefers supply an interface and<br>
> > > > call the C form directly. If the C and Fortran versions are<br>
> > > > both<br>
> > > > functions, there is no change in the source code where the<br>
> > > > function is used.<br>
> > > ><br>
> > > >> -----<br>
> > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp)<br>
> > > >> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base, disp<br>
> > > >><br>
> > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP)<br>
> > > >> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP<br>
> > > ><br>
> > > > It is certainly an oddity that the spec has two forms like<br>
> > > > this.<br>
> > > > Any version of the Fortran standard that supports KIND= in<br>
> > > > INTEGER also supports lower case names and INTENT() attributes.<br>
> > > > Maybe there could be some clean up of this in a future<br>
> > > > revision.<br>
> > > ><br>
> > > > Cheers,<br>
> > > > Bill<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > >> -----<br>
> > > >><br>
> > > ><br>
> > > > --<br>
> > > > Bill Long<br>
> > > > <a href="mailto:longb@cray.com">longb@cray.com</a><br>
> > > > Fortran Technical Support & voice:<br>
> > > > <a href="tel:651-605-9024" value="+16516059024">651-605-9024</a><br>
> > > > Bioinformatics Software Development fax:<br>
> > > > <a href="tel:651-605-9142" value="+16516059142">651-605-9142</a><br>
> > > > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN<br>
> > > > 55101<br>
> > > ><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > mpiwg-fortran mailing list<br>
> > > > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> > > > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
> > ><br>
> > ><br>
> > > --<br>
> > > Jeff Squyres<br>
> > > <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
> > > For corporate legal information go to:<br>
> > > <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
> > ><br>
> > > _______________________________________________<br>
> > > mpiwg-fortran mailing list<br>
> > > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> > > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
> > ><br>
> ><br>
> > --<br>
> > Dr. Rolf Rabenseifner . . . . . . . . . .. email<br>
> > <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> > High Performance Computing Center (HLRS) . phone<br>
> > <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> > University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br>
> > 685-65832<br>
> > Head of Dpmt Parallel Computing . . .<br>
> > <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br>
> > 1.307)<br>
> ><br>
> ><br>
><br>
> --<br>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
> Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
><br>
><br>
<br>
--<br>
Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
</div></div></blockquote></div><br></div>