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
