[MPIWG Fortran] MPI-3 ticket 349: Fortran question

Jim Dinan james.dinan at gmail.com
Fri Dec 20 08:22:05 CST 2013


Jeff,

I don't think that anyone is making an argument that is specific to 32b
architectures.  The concern is that the MPI standard currently requires:

(1) a two's complement architecture where overflow/underflow of signed
arithmetic on an unsigned quantity always results in the right unsigned
value
- OR -
(2) an MPI_Aint type that is 2x the size of an address to ensure that
overflow/underflow never occurs (because MPI_BOTTOM is an arbitrary address
in Fortran)

Given that every system I know of falls into category (1) and there is a
solution (2) for all other systems, I am not trying to recall why we felt
that this problem needs to be solved through new arithmetic routines.  I
believe there was a concern that 128-bit integers are not standard and not
well supported by most languages/architectures, so (2) may not be a
workable solution.  Maybe Dave G [added to cc] remembers our rationale?

 ~Jim.


On Fri, Dec 20, 2013 at 8:35 AM, Jeff Hammond <jeff.science at gmail.com>wrote:

> 32b Blue Gene is dead. We are turning ours off in 2 weeks.
>
> The only 32b arguments should be relevant to ARM and other cell phone
> parts that may run MPI some day.
>
> Jeff
>
> Sent from my iPhone
>
> > On Dec 20, 2013, at 5:04 AM, Rolf Rabenseifner <rabenseifner at hlrs.de>
> wrote:
> >
> > Hi Jim,
> >
> >> I don't think that the proposal is in conflict with sections 2.5.6 or
> >> 4.1.5.  These sections are talking about addresses and not
> >> specifically about how one can use the MPI_Aint type.  We mean to
> >> address only the latter item -- correct usage of the MPI address
> >> integer type.
> >
> > I also do not see a conflict.
> > But I see that the new concept must be explained within these sections.
> > This is about consistency of the whole MPI document.
> >
> >> In terms of where to put the proposed text in the chapter, I suggest
> >> we make that a separate discussion, once the technical issues have
> >> been resolved.
> >
> > As you mentioned below,
> > technically there are two solutions:
> > A. require that disp=addr2-addr1 and addr2=addr1+disp can be
> >   calculated with the intrinsic arithmetic operations - and +.
> >   This would require:
> >      128 bit MPI_Aint on a system that
> >      - uses full 64 bit absolute addresses, AND
> >      - does not have one-s complement arithmetic AND
> >      - MPI_BOTTOM is not defined in the middle
> > B. require that disp=addr2-addr1 and addr2=addr1+disp
> >   is calculated with your two new functions to guarantee
> >   that always 64 bits signed MPI_Aint are enough
> >   to store any 64 bit unsigned absolute addresses.
> >
> > If we decide A, then only an advice to implementers would be fine.
> > If we decide B, then several "corrections" are needed.
> >
> >> I do have a concern, in particular, about section 4.1.12, "Correct
> >> use of Addresses", which seems to suggest that one should be able to
> >> do arithmetic directly on absolute addresses stored in address
> >> integers.  The only way that this could be supported on some
> >> platforms (e.g. one's complement integers) is to make the MPI_Aint
> >> an integer that is larger than an address, so that
> >> overflow/underflow cannot occur.  Because of Fortran's dynamic
> >> MPI_BOTTOM, address integers on such a platform would have to be
> >> 128-bits to ensure that there can be no overflow.
> >>
> >> What's your take on that section?
> >
> > The notations MPI-3.0 page 115 lines 42 and 47 v+i and u-v
> > need not to be interpreted as C and Fortran + and -.
> >
> > One could say that there is a lack of not having defined
> > these operations.
> >
> > I principle, you are right when you expect (as all MPI-readers so far)
> > that + and - on these lines are C and Fortran + and -,
> > and therefore, solution A is required.
> > Note that solution A is not the worst because our systems have IEEE
> > data representation which has one's complements and therefore no Need
> > for doubling the size of MPI_Aint, especially on the pure 32-bit
> Blue-Gene
> > Systems.
> >
> > If one wants to go with B (and this is a free Forum decision)
> > then one should add text to
> >> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and
> >> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35
> > and also to
> > - MPI 3.0 Sect. 4.1.12, page 115 line 48, e.g.,
> >  "Note that v+i and u-v need to be calculated
> >   with MPI_AINT_ADD and MPI_AINT_DIFF."
> > And the two new routines after page 103 line 46.
> >
> > My mails only try to help that proposal B is fully complete
> > and consistent.
> > They are not about whether I would like to have A or B.
> > Because A continues to stay a work-around for B,
> > I would be happy with B.
> >
> > Best regards
> > Rolf
> >
> >
> > ----- Original Message -----
> >> From: "Jim Dinan" <james.dinan at gmail.com>
> >> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> >> Cc: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>,
> "longb" <longb at cray.com>
> >> Sent: Thursday, December 19, 2013 9:55:42 PM
> >> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
> >>
> >>
> >> Hi Rolf,
> >>
> >>
> >> I don't think that the proposal is in conflict with sections 2.5.6 or
> >> 4.1.5.  These sections are talking about addresses and not
> >> specifically about how one can use the MPI_Aint type.  We mean to
> >> address only the latter item -- correct usage of the MPI address
> >> integer type.
> >>
> >>
> >> In terms of where to put the proposed text in the chapter, I suggest
> >> we make that a separate discussion, once the technical issues have
> >> been resolved.
> >>
> >>
> >> I do have a concern, in particular, about section 4.1.12, "Correct
> >> use of Addresses", which seems to suggest that one should be able to
> >> do arithmetic directly on absolute addresses stored in address
> >> integers.  The only way that this could be supported on some
> >> platforms (e.g. one's complement integers) is to make the MPI_Aint
> >> an integer that is larger than an address, so that
> >> overflow/underflow cannot occur.  Because of Fortran's dynamic
> >> MPI_BOTTOM, address integers on such a platform would have to be
> >> 128-bits to ensure that there can be no overflow.
> >>
> >>
> >> What's your take on that section?
> >>
> >>
> >> ~Jim.
> >>
> >>
> >>
> >> On Fri, Dec 13, 2013 at 9:11 AM, Rolf Rabenseifner <
> >> rabenseifner at hlrs.de > wrote:
> >>
> >>
> >> Jim,
> >>
> >>
> >>> Could you provide a list of the specific changes that you feel are
> >>> needed on these tickets?
> >>
> >> I expected that you are doining this.
> >> I only want to mention the locations.
> >>
> >> Your new model differentiates beween
> >> - absolute addresses generated from locations with MPI_GET_ADDRESS
> >> - relative displacements as differences of two absolute addresses
> >> and the needed arithmetic
> >> - relative displacements with normal + - * arithmetic
> >> - absolute addresses and displacments with
> >>   MPI_AINT_ADD and MPI_AINT_DIFF arithmetic
> >>
> >> Therefore:
> >> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and
> >> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35
> >> should reflect this differentiation.
> >>
> >> The proposed rationale in #349 may go at the end of page 102 lines
> >> 28-35.
> >> After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add
> >> MPI_AINT_ADD and MPI_AINT_DIFF.
> >>
> >>
> >> Best regards
> >> Rolf
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Jim Dinan" < james.dinan at gmail.com >
> >>> To: "Rolf Rabenseifner" < rabenseifner at hlrs.de >
> >>> Cc: "MPI-WG Fortran working group" <
> >>> mpiwg-fortran at lists.mpi-forum.org >, "longb" < longb at cray.com >
> >>
> >>
> >>> Sent: Friday, December 13, 2013 1:35:13 PM
> >>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
> >>>
> >>>
> >>> Rolf,
> >>>
> >>>
> >>> 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:
> >>>
> >>>
> >>> MPI_Aint_add --
> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349
> >>> Linked list example updates --
> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402
> >>> MPI_Aint_diff --
> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>> Thank you for helping to improve these tickets!
> >>>
> >>>
> >>> Best,
> >>> ~Jim.
> >>>
> >>>
> >>>
> >>> On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner <
> >>> rabenseifner at hlrs.de > wrote:
> >>>
> >>>
> >>> Dear Jim,
> >>>
> >>> I would like to disagree.
> >>> Looking at #349, I see wording like "base address" etc.
> >>> whereas MPI-3.0 p102.29 uses "absolute address".
> >>>
> >>> And, the ticket does not show the location of the new text,
> >>> nor all the needed background info.
> >>>
> >>> MPI is a standard document and the proposed change
> >>> (absolute addresses can no longer be used in
> >>> normal arithmetic) should be well prepared.
> >>>
> >>> The current text is not ready.
> >>>
> >>> You start to differentiate between "absolute addresses"
> >>> and "relative displacements" and their use of MPI_Aint.
> >>>
> >>> Please have a look at 2.5.6 on page 16.
> >>> This section should be clarified.
> >>>
> >>> Please try to produce one proposal that is complete
> >>> and fits to the standard.
> >>> Voting in small pieces (several tickets) is not the best.
> >>>
> >>>
> >>> Best regards
> >>> Rolf
> >>>
> >>> ----- Original Message -----
> >>>> From: "Jim Dinan" < james.dinan at gmail.com >
> >>>> To: "Rolf Rabenseifner" < rabenseifner at hlrs.de >
> >>>> Cc: "MPI-WG Fortran working group" <
> >>>> mpiwg-fortran at lists.mpi-forum.org >, "longb" < longb at cray.com >,
> >>>> "Jim Dinan"
> >>>> < dinan at mcs.anl.gov >
> >>>
> >>>
> >>>> Sent: Thursday, December 12, 2013 5:51:30 PM
> >>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
> >>>>
> >>>>
> >>>> Hi Rolf,
> >>>>
> >>>>
> >>>> Thanks for the corrections -- I apologize, what I had sent was a
> >>>> very
> >>>> rough draft of the proposal.  I applied your changes to the
> >>>> proposal, cleaned some things up, and added the datatypes
> >>>> examples
> >>>> corrections.  Could you take another look when you get a chance?
> >>>>
> >>>>
> >>>> In terms of proposal logistics, I would like to let MPI_Aint add
> >>>> and
> >>>> diff tickets progress independently.  I agree that they need to
> >>>> be
> >>>> together, and I think we can rely on the chapter committee to
> >>>> handle
> >>>> that if add/diff end up split between two versions of the
> >>>> standard.
> >>>> MPI_Aint_diff should be ready for a reading at the next meeting
> >>>> and
> >>>> MPI_Aint_add will be ready for a first vote.  Given the
> >>>> discussion
> >>>> about MPI 3.x/4.0 timeline yesterday, I think the risk of these
> >>>> not
> >>>> being in the same release of the spec is very low.  Since the
> >>>> Forum
> >>>> has already done all of the work required to move MPI_Aint_add to
> >>>> a
> >>>> vote, I would prefer not to rewind this process by merging it
> >>>> with
> >>>> the diff ticket.
> >>>>
> >>>>
> >>>> ~Jim.
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner <
> >>>> rabenseifner at hlrs.de > wrote:
> >>>>
> >>>>
> >>>> Jim and all,
> >>>>
> >>>> MPI_Get_address((char *) addr1 - (char *) addr2, &result)
> >>>>
> >>>> This is really wrong, because (char *) addr1 - (char *) addr2
> >>>> is not an address and cannot be used as input to MPI_Get_address.
> >>>>
> >>>> (char *) addr1 - (char *) addr2 is a displacement.
> >>>>
> >>>> Both tickets 349 and 404 need to be together, because they
> >>>> are based on a clear distinguishing between
> >>>> - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y
> >>>> - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x,
> >>>> addr_y
> >>>> - relative displacements (diff of two absolute addresses), e.g.
> >>>> dist_xy
> >>>>
> >>>> Your new statement is that calculations like
> >>>>  dist_xy = addr_y - addr_x
> >>>>  addr_y = addr_x + dist_xy
> >>>> need to be done by subroutine calls or functions,
> >>>> because absolute addresses are stored in MPI_Aint variables
> >>>> through some (unknown/strange) mapping,
> >>>> wheras relative displacements are normal unsigned integers
> >>>> that can be used for normal arithmetic.
> >>>>
> >>>> The one ticket must show this clearly and must be integrated into
> >>>> section 4.1.5
> >>>>
> >>>>
> >>>> Best regards
> >>>> Rolf
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>
> >>>>
> >>>>> From: "Jim Dinan" < james.dinan at gmail.com >
> >>>>> To: "Rolf Rabenseifner" < rabenseifner at hlrs.de >
> >>>>> Cc: "MPI-WG Fortran working group" <
> >>>>> mpiwg-fortran at lists.mpi-forum.org >, "longb" < longb at cray.com
> >>>>>> ,
> >>>>> "Jim Dinan"
> >>>>> < dinan at mcs.anl.gov >
> >>>>> Sent: Thursday, December 12, 2013 3:20:41 PM
> >>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
> >>>>>
> >>>>>
> >>>>> Hi Rolf,
> >>>>>
> >>>>>
> >>>>> Thank you very much for the feedback!  Sorry if I forgot to
> >>>>> respond;
> >>>>> the comments definitely were not ignored.  We discussed the
> >>>>> Aint
> >>>>> difference calculation in the working group and decided to
> >>>>> create
> >>>>> an
> >>>>> additional ticket for MPI_Aint_disp.  We did not see a clean
> >>>>> way
> >>>>> to
> >>>>> handle this in MPI_Aint_add, because both arguments need to be
> >>>>> handled as unsigned in the arithmetic.
> >>>>>
> >>>>>
> >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404
> >>>>>
> >>>>>
> >>>>>
> >>>>> I have a list of fixes the to the datatypes examples that I'll
> >>>>> post
> >>>>> to the ticket soon.
> >>>>>
> >>>>>
> >>>>> Jeff Squyres is also helping us move the MPI_Aint arithmetic
> >>>>> routines
> >>>>> to functions in the Fortran bindings.  Should be done today.
> >>>>>
> >>>>>
> >>>>> Were there any other concerns that we missed?
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>> ~Jim.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner <
> >>>>> rabenseifner at hlrs.de > wrote:
> >>>>>
> >>>>>
> >>>>> Jeff and Bill,
> >>>>>
> >>>>> <
> >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22
> >>>>> was ignored.
> >>>>> The answer seems to be yes and the clear implication is that
> >>>>> we need also a routine to calculate disp := addr2-addr1
> >>>>>
> >>>>> About the Fortran Interfaces:
> >>>>> We should keep the old style without INTENT, because for the
> >>>>> old-style
> >>>>> the implementor has the freedom to add INTENT as he/she wants
> >>>>> and it is still compliant with the outcome of the definition.
> >>>>>
> >>>>> I do not see, why we have a function in C and a subroutine
> >>>>> in Fortran.
> >>>>> Like MPI_Wtime, in all three languages (C, new and old
> >>>>> Fortran),
> >>>>> we should do the same.
> >>>>>
> >>>>> Best regards
> >>>>> Rolf
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Jeff Squyres (jsquyres)" < jsquyres at cisco.com >
> >>>>>> To: "< longb at cray.com >" < longb at cray.com >, "MPI-WG Fortran
> >>>>>> working group" < mpiwg-fortran at lists.mpi-forum.org >
> >>>>>> Sent: Thursday, December 12, 2013 12:17:40 AM
> >>>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran
> >>>>>> question
> >>>>>>
> >>>>>> Sounds good to me.
> >>>>>>
> >>>>>> Rolf -- is there any MPI reason we would not want to do this?
> >>>>>>
> >>>>>>
> >>>>>> On Dec 11, 2013, at 4:41 PM, Bill Long < longb at cray.com >
> >>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote:
> >>>>>>>> This ticket got a formal reading today at the Forum:
> >>>>>>>>
> >>>>>>>>    http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349
> >>>>>>>>    (as of this writing, there's still a BIND(C) in there,
> >>>>>>>> but
> >>>>>>>> it
> >>>>>>>>    will be removed shortly)
> >>>>>>>>
> >>>>>>>> The function is basically intended to perform a
> >>>>>>>> mathematical
> >>>>>>>> operation.  As such, I think that the 2 Fortran bindings
> >>>>>>>> should
> >>>>>>>> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME).
> >>>>>>>>
> >>>>>>>> Do you agree?  If so, the ticket author (Jim Dinan) is
> >>>>>>>> amenable
> >>>>>>>> to
> >>>>>>>> changing the Fortran bindings to the following (and I'm
> >>>>>>>> assuming
> >>>>>>>> I have the syntax below correct, but feel free to correct
> >>>>>>>> me
> >>>>>>>> if
> >>>>>>>> they're wrong):
> >>>>>>>
> >>>>>>> Certainly it makes more sense for these to be functions in
> >>>>>>> Fortran.
> >>>>>>> Particularly if the programmer prefers supply an interface
> >>>>>>> and
> >>>>>>> call the C form directly.  If the C and Fortran versions
> >>>>>>> are
> >>>>>>> both
> >>>>>>> functions, there is no change in the source code where the
> >>>>>>> function is used.
> >>>>>>>
> >>>>>>>> -----
> >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp)
> >>>>>>>>    INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) ::  base,
> >>>>>>>> disp
> >>>>>>>>
> >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP)
> >>>>>>>>    INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP
> >>>>>>>
> >>>>>>> It is certainly an oddity that the spec has two forms like
> >>>>>>> this.
> >>>>>>> Any version of the Fortran standard that supports KIND= in
> >>>>>>> INTEGER also supports lower case names and INTENT()
> >>>>>>> attributes.
> >>>>>>>  Maybe there could be some clean up of this in a future
> >>>>>>> revision.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Bill
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----
> >>>>>>>
> >>>>>>> --
> >>>>>>> Bill Long
> >>>>>>> longb at cray.com
> >>>>>>> Fortran Technical Support    &                 voice:
> >>>>>>> 651-605-9024
> >>>>>>> Bioinformatics Software Development            fax:
> >>>>>>> 651-605-9142
> >>>>>>> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul,
> >>>>>>> MN
> >>>>>>> 55101
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> mpiwg-fortran mailing list
> >>>>>>> mpiwg-fortran at lists.mpi-forum.org
> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jeff Squyres
> >>>>>> jsquyres at cisco.com
> >>>>>> For corporate legal information go to:
> >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> mpiwg-fortran mailing list
> >>>>>> mpiwg-fortran at lists.mpi-forum.org
> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>>>
> >>>>> --
> >>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
> >>>>> rabenseifner at hlrs.de
> >>>>> High Performance Computing Center (HLRS) . phone
> >>>>> ++49(0)711/685-65530
> >>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
> >>>>> 685-65832
> >>>>> Head of Dpmt Parallel Computing . . .
> >>>>> www.hlrs.de/people/rabenseifner
> >>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room
> >>>>> 1.307)
> >>>>
> >>>> --
> >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
> >>>> rabenseifner at hlrs.de
> >>>> High Performance Computing Center (HLRS) . phone
> >>>> ++49(0)711/685-65530
> >>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
> >>>> 685-65832
> >>>> Head of Dpmt Parallel Computing . . .
> >>>> www.hlrs.de/people/rabenseifner
> >>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room
> >>>> 1.307)
> >>>
> >>> --
> >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
> >>> rabenseifner at hlrs.de
> >>> High Performance Computing Center (HLRS) . phone
> >>> ++49(0)711/685-65530
> >>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
> >>> 685-65832
> >>> Head of Dpmt Parallel Computing . . .
> >>> www.hlrs.de/people/rabenseifner
> >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room
> >>> 1.307)
> >>
> >> --
> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
> >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> >> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)
> >
> > --
> > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
> > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)
> > _______________________________________________
> > mpiwg-fortran mailing list
> > mpiwg-fortran at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20131220/7b6b7a9d/attachment-0001.html>


More information about the mpiwg-fortran mailing list