On Thu, Feb 18, 2016 at 1:31 PM, Jeff Squyres (jsquyres) <jsquyres@cisco.com> wrote:

On Feb 18, 2016, at 3:55 PM, Rolf Rabenseifner <rabenseifner@hlrs.de> wrote:
>
> I would prefer a solution where an application or middlware can check at
> runtime whether the Fortran MPI datatypes exist, i.e., I like mpich's
> solution. It is more simple than all methods that People must check prior
> to compile and must remove or Change parts of there software.

The reason that JeffH and Jed hate this solution is because it makes it quite difficult for an application to know whether the MPI has Fortran support or not -- they basically have to compile an MPI application *and then run it* to see if the datatypes are actually MPI_DATATYPE_NULL.

Well, technically, I can look up how every implementation implements this when it isn't supported and do a compile-time check for it, but this is a truly terrible solution (which I have demonstrated below). I do not want an MPI application to compile if it is certain to not work.

#if defined(MPICH)

#if defined(MPI_INTEGER) && MPI_INTEGER=="((MPI_Datatype)MPI_DATATYPE_NULL)"

#error If you want Fortran, get a Fortran!

#endif

Doing this inside a GNU Autoconf/configure script is very, very difficult because of the huge differences in how you launch MPI applications across different HPC environments.

Indeed. It makes cross-compilation impossible on systems like Blue Gene and Cray, which do not allow one to launch an MPI application on the login node, and likely not the service node.

Their (strong) preference is that you can have a simple compilation test in the GNU Autoconf/configure script that just tries to compile something like the following:

-----
#include <mpi.h>
MPI_Datatype foo = MPI_INTEGER;
-----

If that compiles, then your MPI has Fortran support.
If it doesn't compile, your MPI doesn't have Fortran support.

Exactly.

> In the moment,in the case of a missing accompanying Fortran Compiler,
> an application or middleware that wants to handle
> MPI Fortran datatypes must handle both cases
> (1) mpi.h does not provide a specific MPI Fortran datatype

This is what I want.

> (2) mpi.h provides this MPI Fortran datatype as MPI_DATATYPE_NULL
>

I think this is what is implemented today and it is the only reasonable implementation of what the text says (and doesn't say) right now.

> The additional case, that it is mapped to a real datatype is not
> an exception, because it defines some sort of accompanying Fortran Compiler.
>
> I would prefer that the MPI standard defines, which of the two
> options should be implemented.

I think JeffH and Jed want (1).

I think I want (1), too.

You are as intelligent as your name suggests :-)

> As said at the beginning, I would prefer (1),
> - as mpich is doing it in general, and
> - OMPI is doing it partially,
> whereas (2) was not done by mpich nor by OMPI.

As I showed earlier, MPICH does 2. Do I misunderstand you?

I think you have (1) and (2) backwards in this paragraph.

I think I am confused now.

Jeff

--
Jeff Squyres
jsquyres@cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________
mpiwg-fortran mailing list
mpiwg-fortran@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

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