Users
Date: February 10, 2016 at 1:09:39 AM
To: Gilles Gouaillardet , Open MPI Users
Subject: Re: [OMPI users] OMPI users] Fortran vs C reductions
> Gilles Gouaillardet writes:
> >> implementation. Must I compile in support for being called with
> >> MPI_DOUBLE_COMPLEX?
> &
Gilles Gouaillardet writes:
>> implementation. Must I compile in support for being called with
>> MPI_DOUBLE_COMPLEX?
>>
> does that really matter ?
Possibly. For example, if the library needed to define some static
data, its setup might involve communicating values before being called
with tha
Jed,
On 2/10/2016 12:18 AM, Jed Brown wrote:
Did anyone suggest violating the standard?
if i understand correctly what George wrote earlier, then yes, removing
predefined datatypes from the header files can be seen as a violation of
the standard
in your configure script, you can simply try to
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 wrote:
> The text you pinpoint is clear about the target: the MPI bindings. The
> question here is no
The only agreement we have so far is that from the perspective of a user
having a questionable usage of a particular datatype in a extremely
particular reduction operation the situation can be perceived as unfriendly.
Your argument is that if in a particular OMPI installation Fortran support
is no
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 wrote:
> "MPI-3.0 (and later) compliant Fortran bindi
"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 m
Dave Love writes:
> Jed Brown writes:
>
>> Isn't that entirely dependent on the Fortran compiler? There is no
>> universal requirement that there be a relationship between Fortran
>> INTEGER and C int, for example.
>
> In case it's not generally obvious: the compiler _and its options_.
> You c
Gilles Gouaillardet writes:
> Jed,
>
> my 0.02US$
>
> we recently had a kind of similar discussion about MPI_DATATYPE_NULL, and
> we concluded
> ompi should do its best to implement the MPI standard, and not what some of
> us think the standard should be.
Did anyone suggest violating the standar
On Feb 9, 2016, at 12:21 AM, George Bosilca 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,
Jed Brown writes:
> George Bosilca writes:
>
>> 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 t
Jed,
my 0.02US$
we recently had a kind of similar discussion about MPI_DATATYPE_NULL, and
we concluded
ompi should do its best to implement the MPI standard, and not what some of
us think the standard should be.
in your configure script, you can simply try to compile a simple fortran
MPI hello w
George Bosilca writes:
> 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
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
Awesome; thanks Gilles.
> On Feb 8, 2016, at 9:29 AM, Gilles Gouaillardet
> wrote:
>
> ok, will do
>
> Cheers,
>
> Gilles
>
> On Monday, February 8, 2016, Jeff Squyres (jsquyres)
> wrote:
> I like your suggestion better -- if we can somehow report during the
> compile/link that the reaso
ok, will do
Cheers,
Gilles
On Monday, February 8, 2016, Jeff Squyres (jsquyres)
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 prefe
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., th
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 run
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 su
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 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
20 matches
Mail list logo
