Then we should clarify the spec, because it's unreasonable to require MPI
support a Fortran type without being able to know its representation.

Jeff

On Tuesday, February 9, 2016, George Bosilca <bosi...@icl.utk.edu> wrote:

> The text you pinpoint is clear about the target: the MPI bindings. The
> question here is not about bindings, but about a predefined datatype, a
> case where I don't think the text applies.
>
>   George.
>
>
> On Tue, Feb 9, 2016 at 6:17 PM, Jeff Hammond <jeff.scie...@gmail.com
> <javascript:_e(%7B%7D,'cvml','jeff.scie...@gmail.com');>> wrote:
>
>> "MPI-3.0 (and later) compliant Fortran bindings are not only a property
>> of the MPI library itself, but rather a property of an MPI library together
>> with the Fortran compiler suite for which it is compiled." (MPI 3.1 Section
>> 17.1.7).
>>
>> Of course, implementations can provide support in excess of the minimum
>> required by the standard, provided that support remains compliant with the
>> standard.
>>
>> Jeff
>>
>>
>> On Mon, Feb 8, 2016 at 9:21 PM, George Bosilca <bosi...@icl.utk.edu
>> <javascript:_e(%7B%7D,'cvml','bosi...@icl.utk.edu');>> wrote:
>> >
>> > Sorry to spoil the fun here, but this proposal is a very bad idea. It
>> is mandated by the MPI standard, page 25 line 27 (v3.1), not only to
>> provide all predefined datatypes, but to have support for them. There are
>> optional datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base
>> predefined datatype for MPI_2DOUBLE_PRECISION) is not one of them.
>> >
>> > Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As
>> these languages are interoperable, and there is no explicit conversion
>> function, it is safe to assume this is the case. Thus, is seems to me
>> absolutely legal to provide the MPI-required support for DOUBLE PRECISION
>> despite the fact that Fortran support is not enabled.
>> >
>> > Now taking a closer look at the op, I see nothing in the standard the
>> would require to provide the op if the corresponding language is not
>> supported. While it could be nice (as a convenience for the users and also
>> because there is no technical reason not to) to enable the loc op, on non
>> native datatypes, this is not mandatory. Thus, the current behavior exposed
>> by Open MPI is acceptable from the standard perspective.
>> >
>> >   George.
>> >
>> >
>> > On Mon, Feb 8, 2016 at 4:35 PM, Jeff Squyres (jsquyres) <
>> jsquy...@cisco.com <javascript:_e(%7B%7D,'cvml','jsquy...@cisco.com');>>
>> wrote:
>> >>
>> >> Awesome; thanks Gilles.
>> >>
>> >>
>> >> > On Feb 8, 2016, at 9:29 AM, Gilles Gouaillardet <
>> gilles.gouaillar...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','gilles.gouaillar...@gmail.com');>> wrote:
>> >> >
>> >> > ok, will do
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Gilles
>> >> >
>> >> > On Monday, February 8, 2016, Jeff Squyres (jsquyres) <
>> jsquy...@cisco.com <javascript:_e(%7B%7D,'cvml','jsquy...@cisco.com');>>
>> wrote:
>> >> > I like your suggestion better -- if we can somehow report during the
>> compile/link that the reason for the error is because Open MPI was not
>> compiled with Fortran support, that would definitely be preferable.
>> >> >
>> >> > FWIW: my suggestion was because I wanted to convey the *reason* for
>> the error (i.e., that OMPI has no Fortran support), and a pragma-based
>> solution didn't occur to me.  I didn't want to follow Gilles' suggestion of
>> just removing the symbols, because that will lead to other confusion (e.g.,
>> "Hey, Open MPI is not compliant because it doesn't have Fortran datatypes
>> available in C!").
>> >> >
>> >> > Gilles: do you want to poke around and see if you can make any of
>> Jeff's suggestions work out nicely?  (i.e., give some kind of compile/link
>> error that states that Open MPI was not built with Fortran support?)
>> >> >
>> >> >
>> >> > On Feb 8, 2016, at 8:55 AM, Jeff Hammond <jeff.scie...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','jeff.scie...@gmail.com');>> wrote:
>> >> > >
>> >> > > Waiting until runtime to issue this error is a terrible idea,
>> because then the PETSc team (among others) will disparage you for allowing
>> a user to successfully build against an unusable library.  They are
>> on-record numerous times in the past as to the evils of e.g. no-op symbols
>> in MPI or other runtime libraries, since this means that compile- and
>> link-based tests pass, even though nothing good will happen when the user
>> employs them in an application.
>> >> > >
>> >> > > The right thing to do is what Gilles proposed: do not define the
>> types in mpi.h so that it is impossible to compile C code with Fortran
>> datatypes, if Fortran datatypes are not supported.  There are more and less
>> effective ways to do this, in terms of letting the user know what is
>> happening.  For example, you can just not define them, which might confuse
>> novices who don't know how to read error messages (HPC users are frequent
>> offenders).
>> >> > >
>> >> > > You could use e.g.:
>> >> > >
>> >> > > #define MPI_DOUBLE_PRECISION choke me No Fortran support when
>> library was compiled!
>> >> > >
>> >> > > Unfortunately, Clang colorized output emphasizes the wrong problem
>> here, and ICC doesn't even echo the message at all in its error message.
>> GCC issues the same error four times, and makes it relatively hard to miss
>> the message.
>> >> > >
>> >> > > If the following GCC extension is supported, along with C99/C++11,
>> you could do this:
>> >> > >
>> >> > > #define MPI_DOUBLE_PRECISION _Pragma("GCC error \"MPI was not
>> compiled with Fortran support\"")
>> >> > >
>> >> > > For the _functions_ that require Fortran support, you can use e.g.
>> __attribute__((error("no Fortran"))) on the function declaration, although
>> neither ICC nor Clang support this, and it ends up throwing two error
>> messages when compiled (only one - the right one - when only preprocessed),
>> which might confuse the same folks that it is trying to help.
>> >> > >
>> >> > > Best,
>> >> > >
>> >> > > Jeff
>> >> > >
>> >> > > On Mon, Feb 8, 2016 at 5:14 AM, Jeff Squyres (jsquyres) <
>> jsquy...@cisco.com <javascript:_e(%7B%7D,'cvml','jsquy...@cisco.com');>>
>> wrote:
>> >> > > The issue at hand is trying to help the user figure out that they
>> have an open MPI built without fortran support.
>> >> > >
>> >> > > Perhaps we should improve the error reporting at run time to
>> display something about the fact that you used a fortran data type but have
>> an OMPI that was compiled without fortran support.
>> >> > >
>> >> > > Sent from my phone. No type good.
>> >> > >
>> >> > > On Feb 8, 2016, at 4:00 AM, Gilles Gouaillardet <
>> gilles.gouaillar...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','gilles.gouaillar...@gmail.com');>> wrote:
>> >> > >
>> >> > >> That being said, should we remove these fortran types from
>> include files and libs when ompi is configure'd without fortran support ?
>> >> > >>
>> >> > >> Cheers,
>> >> > >>
>> >> > >> Gilles
>> >> > >>
>> >> > >> Jeff Hammond <jeff.scie...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','jeff.scie...@gmail.com');>> wrote:
>> >> > >>
>> >> > >> > BTW: is there a reason you don't want to just use the C
>> datatypes?  The fundamental output of the index is an integer value --
>> casting it to a float of some flavor doesn't fundamentally change its value.
>> >> > >>
>> >> > >> The code in question is not mine.  I have suggested to the
>> developers that they should use the correct C types.  The reason I became
>> aware of this issue is that one of my colleagues compiled and ran this code
>> on a system where OpenMPI was built without Fortran support and the code
>> started failing with errors from MPI which were not seen on other systems.
>> >> > >>
>> >> > >>
>> >> > >> If you use an MPI library compiled without Fortran support, you
>> should expect precisely nothing related to Fortran to work.  You might get
>> more than this because the universe is being nice to you, but you should
>> treat it as serendipity when something works, not a bug when something
>> doesn't.
>> >> > >>
>> >> > >> Jeff
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> Jeff Hammond
>> >> > >> jeff.scie...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','jeff.scie...@gmail.com');>
>> >> > >> http://jeffhammond.github.io/
>> >> > >> _______________________________________________
>> >> > >> users mailing list
>> >> > >> us...@open-mpi.org
>> <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> >> > >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> >> > >> Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28459.php
>> >> > >
>> >> > > _______________________________________________
>> >> > > users mailing list
>> >> > > us...@open-mpi.org
>> <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> >> > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> >> > > Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28460.php
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Jeff Hammond
>> >> > > jeff.scie...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','jeff.scie...@gmail.com');>
>> >> > > http://jeffhammond.github.io/
>> >> > > _______________________________________________
>> >> > > users mailing list
>> >> > > us...@open-mpi.org
>> <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> >> > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> >> > > Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28461.php
>> >> >
>> >> >
>> >> > --
>> >> > Jeff Squyres
>> >> > jsquy...@cisco.com
>> <javascript:_e(%7B%7D,'cvml','jsquy...@cisco.com');>
>> >> > For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> >> >
>> >> > _______________________________________________
>> >> > users mailing list
>> >> > us...@open-mpi.org
>> <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> >> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> >> > Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28463.php
>> >> > _______________________________________________
>> >> > users mailing list
>> >> > us...@open-mpi.org
>> <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> >> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> >> > Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28465.php
>> >>
>> >>
>> >> --
>> >> Jeff Squyres
>> >> jsquy...@cisco.com
>> <javascript:_e(%7B%7D,'cvml','jsquy...@cisco.com');>
>> >> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> >>
>> >> _______________________________________________
>> >> users mailing list
>> >> us...@open-mpi.org
>> <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> >> Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28466.php
>> >
>> >
>> >
>> > _______________________________________________
>> > users mailing list
>> > us...@open-mpi.org <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> > Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28469.php
>>
>>
>>
>>
>> --
>> Jeff Hammond
>> jeff.scie...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','jeff.scie...@gmail.com');>
>> http://jeffhammond.github.io/
>>
>> _______________________________________________
>> users mailing list
>> us...@open-mpi.org <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');>
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28477.php
>>
>
>

-- 
Jeff Hammond
jeff.scie...@gmail.com
http://jeffhammond.github.io/

Reply via email to