Jan, You can use MPI_Type_match_size ( https://www.open-mpi.org/doc/v2.0/man3/MPI_Type_match_size.3.php) to find the MPI type that meets certain requirements.
George. On Wed, Dec 21, 2016 at 3:16 AM, 🐋 Jan Hegewald <jan.hegew...@awi.de> wrote: > Hi Jeff et al, > > > On 20 Dec 2016, at 20:23, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > > > > Fair enough. > > > > But be aware that if you are building MPICH with double-width Fortran > types and single-width C types, you might want to verify that MPICH is > actually working properly. > > yes. This episode certainly did bring the possible side effects of the > "-fdefault-real-8" on my list. But for now I just want this Wtime to work (: > > > > > Open MPI is refusing to configure because for each Fortran type X, it > looks for a corresponding C type Y. If it can't find a correspondence, > then it fails/aborts configure (i.e., it lets a human figure it out -- > usually by ensuring that there are equivalent flags for the C/C++ and > Fortran compilers). At least in Open MPI, having a C/Fortran type > equivalence is necessary for reduction operations (because we do them in > C). I don't know if MPICH has this restriction or not. > > > > In your case, Open MPI is failing to find a basic (single-width) C type > that corresponds to the (double-width) Fortran type COMPLEX. This may not > matter for your specific application, but we tend to take an all-or-nothing > approach to configuration/building (i.e., we won't knowingly build a > half-functional Open MPI). > > > > I hope that our rationale for this design choice at least makes sense. > > > > Also, if you are compiling your application with double-width Fortran > types but are compiling your application with single-width Fortran types > (this is how the thread started), that's quite dangerous -- your MPI > doesn't agree with your application on the size of Fortran types, and all > types of unpredictable hilarity can/will ensure. > > Yes, this may lead to trouble. I am glad I found this -fdefault-real-8 in > our setup! > > > > > That's exactly why you were getting a 0 from MPI_WTIME() in Open MPI -- > Open MPI was returning an 8 byte DOUBLE PRECISION, but your application was > looking for a 16 byte DOUBLE PRECISION. > > > > I can't tell from your replies, but I'm guessing you compiled MPICH with > double-width Fortran types and single-width C types. In this case, you > should get correct values back from MPI_WTIME (because both MPI and your > application use 16-byte DOUBLE PRECISIONS). What is an open question is > how MPICH treats reductions on Fortran types (i.e., whether they are done > in C or Fortran), and/or whether it matters for your application. > > I installed the default homebrew mpich. Most HPC systems use a vendor > tweaked MPI anyway. How can I always be sure of the floating point widths > it has been compiled with? > > Cheers, > Jan Hegewald > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
