Dave,
As an OpenMPI developer, i strongly encourage everyone to use Fortran
2008 bindings
(e.g. use mpi_f08) whenever possible. Main reason is some ambiguous
stuff from legacy fortran bindings
have been removed, and type checking is much better and hence less error
prone.
since Fortran modules are not interoperable, that could allow me to
avoid answering your request ...
Note mangling is an other source of issues in Fortran (no/single/double
underscore, or even all lower case or all upper case) regarding
interoperability.
MPI_Sizeof is just a nightmare in (legacy ?) Fortran, for example :
- gfortran 4.8.5 (stock compiler in RHEL7) does not support MPI_Sizeof
- gfortran (probably since 4.9.2, tested with 5.2.0, a snapshot of
upcoming 6.0.0) does support up to 7 dimensions
- intel compiler (at least the recent ones) does support up to 15 dimensions
the common denominator here is "no support for MPI_Sizeof in legacy
Fortran".
a less extreme option could be to add a configure parameter to force the
number of dimensions
(e.g. 0, 7 or 15). If you force it to 7, it will be up to you to explain
your endusers why MPI_Sizeof does not
work with 10 dimesions array in Intel Fortran ...
doing that would be basically providing a workaround to do something
that is discouraged.
("something" here means 'include mpif.h" and assume everything will be
fine, whereas use of
Fortran 2008 bindings is encouraged)
imho, the "right" way is to use modules and several OpenMPI install dirs.
(e.g. module load compiler/<vendor>/<version>/<option>; module load ompi,
properly configured modules will do the magic and pick the ompi tree
that works)
that obviously requires more disk space and time to build, but on the
bright side,
disk is getting cheaper and having happy endusers have always been
priceless.
We could somehow automate what Ben Menadue is doing
(e.g. use one directory per vendor (or vendor x version x "-i8 or not")).
i am sure it would make vendors and those who use gnu + one other vendor
happy,
but i am not sure that could easily work with more than two vendors.
i need to give it some thoughts and let other folks comment about that.
i will double check the documentation per your recommendation.
Cheers,
Gilles
FWIW, from ompi/mpi/fortran/base/gen-mpi-sizeof.pl
# Script to generate the overloaded MPI_SIZEOF interfaces and
# subroutine bodies for both the mpi and mpi_f08 modules.
#
# This script won't really be necessary (i.e., be a whole lot simpler)
# when Fortran compilers uniformly supprort TS 29113 -- i.e., they
# support dimension(..). Using dimension(..), you can have just *one*
# procedure for every type, and dimension(..) will resolve to both
# scalars and all possible ranks.
#
# But for the meantime, we generate for all ranks so that we support
# as many compilers as possible. :-\ (we don't check the compiler and
# see if it supports dimension(..) and do a different generation based
# on that, because we already have a zillion different options in the
# Fortran support -- let's just do MPI_Sizeof this one way in the name
# of simplicity...).
#
On 3/4/2016 12:22 PM, Dave Turner wrote:
All,
I think that a GNU build of OpenMPI will allow compiling with both
gfortan and ifort, so I think OMPI_FC is useful. I'd like to see it fully
supported if possible, so if the higher-dimensions in mpif-sizeof.h are
not vital and there is another way of accomplishing the same thing I think
it would be useful to address.
If not, I would at least like to see some warnings in the
documentation
of the OMPI_FC section that would list the cases like this where it
will fail.
Dave
On Thu, Mar 3, 2016 at 9:07 PM, Larry Baker <ba...@usgs.gov
<mailto:ba...@usgs.gov>> wrote:
Dave,
Both Gilles and Chris raise important points. You really cannot
expect to mix modules from two different Fortran compilers in a
single executable. There is no requirement placed on a compiler
by the Fortran standard for what object language it should use,
how the information in modules is made available across
compilation units, or the procedure calling conventions. This
makes me wonder, as you do, what the point is of the OMPI_CC and
OMPI_FC environment variables? I do think that Intel has tried to
make their objects interoperable with GCC objects. That is a
link-time issue. You are encountering compile-time issues.
Gilles says whatever mpif-sizeof.h was intended to define, it
cannot be done in gfortran. Even if mpif-sizeof.h generated for
an Intel compiler was standard-conforming (so the errors you
encountered are not show stoppers), I'm not sure you would be able
to get past the incompatibility between the internal formats used
by each compiler to store module definitions and declarations for
later USE by another compilation unit. I think your expectations
cannot be fulfilled because of the compilers, not because of OpenMPI.
Larry Baker
US Geological Survey
650-329-5608 <tel:650-329-5608>
ba...@usgs.gov <mailto:ba...@usgs.gov>
On 3 Mar 2016, at 6:39 PM, Dave Turner wrote:
Gilles,
I don't see the point of having the OMPI_CC and OMPI_FC
environment
variables at all if you're saying that we shouldn't expect them
to work. I
actually do think they work fine if you do a GNU build and use
them to
specify the Intel compilers. I also think it works fine when you
do an
Intel build and compile with gcc. So to me it just looks like
that one
include file is the problem.
Dave
On Thu, Mar 3, 2016 at 8:02 PM, Gilles Gouaillardet
<gil...@rist.or.jp <mailto:gil...@rist.or.jp>> wrote:
Dave,
you should not expect anything when mixing Fortran compilers
(and to be on the safe side, you might not expect much when
mixing C/C++ compilers too,
for example, if you built ompi with intel and use gcc for
your app, gcc might complain about unresolved symbols from
the intel runtime)
if you compile OpenMPI with gfortran 4.8.5, the automatically
generated mpif-sizeof.h contains
! Sad panda.
!
! This compiler does not support the Right Stuff to enable
MPI_SIZEOF.
! Specifically: we need support for the INTERFACE keyword,
! ISO_FORTRAN_ENV, and the STORAGE_SIZE() intrinsic on all types.
! Apparently, this compiler does not support both of those
things, so
! this file will be (effecitvely) blank (i.e., we didn't bother
! generating the necessary stuff for MPI_SIZEOF because the
compiler
! doesn't support
! it).
!
! If you want support for MPI_SIZEOF, please use a different
Fortran
! compiler to build Open MPI.
intel fortran compilers have the right stuff, so
mpif-sizeof.h is usable, and you get something very different.
Cheers,
Gilles
On 3/4/2016 10:17 AM, Dave Turner wrote:
My understanding is that OpenMPI built with either Intel or
GNU compilers should be able to use the other compilers
using the
OMPI_CC and OMPI_FC environmental variables.
For OpenMPI-1.8.8 built with Intel compilers, if you try to
compile any code that includes mpif.h using OMPI_FC=gfortran it
fails. The Intel build creates mpi-sizeof.h that dimensions
arrays to more than 6 dimensions which gfortran cannot handle.
The example below illustrates this.
I wasn't able to find any other reports like this on the
web, and I don't see any way of specifying a path to an
alternate
mpif.h include file. This looks to be a bug to me, but
please let
me know if I missed a config flag somewhere.
Dave Turner
Selene cat bugtest.F
! Program to illustrate bug when OpenMPI is compiled with Intel
! compilers but run using OMPI_FC=gfortran.
PROGRAM BUGTEST
INCLUDE "mpif.h"
END
Selene cat go
#!/bin/bash
echo "Compile test using default ifort"
mpifort --version
mpifort bugtest.F -o bugtest_ifort
echo "Compile test using gfortan when OpenMPI was compiled
with ifort/icc"
export OMPI_FC=gfortran
mpifort --version
mpifort bugtest.F -o bugtest_gfortran
Selene ./go
Compile test using default ifort
ifort (IFORT) 15.0.3 20150407
Copyright (C) 1985-2015 Intel Corporation. All rights reserved.
Compile test using gfortan when OpenMPI was compiled with
ifort/icc
GNU Fortran (Gentoo 4.9.3 p1.4, pie-0.6.4) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted
by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named
COPYING
mpif-sizeof.h:75.48:
Included at mpif.h:61:
Included at bugtest.F:6:
COMPLEX(REAL128), DIMENSION(1,1,1,1,1,1,1,*)::x
1
Error: Array specification at (1) has more than 7 dimensions
mpif-sizeof.h:82.48:
Included at mpif.h:61:
Included at bugtest.F:6:
COMPLEX(REAL128), DIMENSION(1,1,1,1,1,1,1,1,*)::x
1
Error: Array specification at (1) has more than 7 dimensions
mpif-sizeof.h:89.48:
Included at mpif.h:61:
Included at bugtest.F:6:
COMPLEX(REAL128), DIMENSION(1,1,1,1,1,1,1,1,1,*)::x
1
Error: Array specification at (1) has more than 7 dimensions
[ More of the same errors have been clipped ]
--
Work: davetur...@ksu.edu <mailto:davetur...@ksu.edu> (785)
532-7791 <tel:%28785%29%20532-7791>
2219 Durland, Manhattan KS 66502
Home: drdavetur...@gmail.com <mailto:drdavetur...@gmail.com>
cell: (785) 770-5929 <tel:%28785%29%20770-5929>
_______________________________________________
devel mailing list
de...@open-mpi.org <mailto:de...@open-mpi.org>
Subscription:http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this
post:http://www.open-mpi.org/community/lists/devel/2016/03/18671.php
--
Work: davetur...@ksu.edu <mailto:davetur...@ksu.edu> (785)
532-7791 <tel:%28785%29%20532-7791>
2219 Durland, Manhattan KS 66502
Home: drdavetur...@gmail.com <mailto:drdavetur...@gmail.com>
cell: (785) 770-5929 <tel:%28785%29%20770-5929>
_______________________________________________
devel mailing list
de...@open-mpi.org <mailto:de...@open-mpi.org>
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post:
http://www.open-mpi.org/community/lists/devel/2016/03/18678.php
--
Work: davetur...@ksu.edu <mailto:davetur...@ksu.edu> (785) 532-7791
2219 Durland, Manhattan KS 66502
Home: drdavetur...@gmail.com <mailto:drdavetur...@gmail.com>
cell: (785) 770-5929
