Hi, Dominik,
gfortran and ifort produce Fortran module files (*.mod) with completely
different and hence incompatible formats. You cannot use a module compiled
with gfortran in ifort and vice versa. That's why many Fortran libraries
come with explicit module interface definitions that have to be c
Hi,
thanks, I remember that now. So it is a "documentation bug" in that
particular FAQ entry.
Dominik
On 03/13/2013 09:58 AM, Iliev, Hristo wrote:
Hi, Dominik,
gfortran and ifort produce Fortran module files (*.mod) with completely
different and hence incompatible formats. You cannot use a
No, it is not a documentation bug. You are replacing the Fortran compiler
that the wrapper uses with a compiler from a completely different family.
The FAQ entry advises against messing with the wrapper configuration,
selected during library build time. Listing all possible effects that might
resul
AFAIK the GNU people change the Fotran Module syntax every time they get any
chance for doing it :-(
So openmpi compiled with 4.4.6 (sys-default for RHEL 6.x) definitely does not
work with 4.5, 4.6, 4.7 versions of gfortran.
Intel 'ifort' compiler build modules which are compatible from 11
Yes, sure. My point is just that "strongly discouraged" (as per the FAQ)
is different from "simply will not work at all". I find that a bit
confusing, especially since in other areas of the FAQ, explicit
workarounds are stated, e.g. on how to build a Makefile rule to extract
flags from an mpiwr
Dear MPI users,
I have a small serial program that reads a sparse matrix from a file
and factorizes it
using the sparse direct solvers included in PARDISO MKL. When I execute
the program with
the matrix of interest, PARDISO factorizes it succesfully. No SIGSEV is
produced. However,
if I transf
Fair point; the "don't do that" aspect of changing compilers with middleware is
exactly the type of information that you want to be able to google for. I've
added the following paragraph to the FAQ entry
http://www.open-mpi.org/faq/?category=mpi-apps#override-wrappers-after-v1.0:
-
Note th
perfect, thanks!
On 03/13/2013 12:21 PM, Jeff Squyres (jsquyres) wrote:
Fair point; the "don't do that" aspect of changing compilers with middleware is
exactly the type of information that you want to be able to google for. I've added the
following paragraph to the FAQ entry
http://www.open-
Hi,
On Feb 21, Jeff Squyres announced Open MPI 1.6.4. However,
on the Open MPI home page, 1.6.3 is still indicated as the
current release. Going to the download page shows 1.6.4 as
the current release, so I think the problem is isolated to
the home page. Thanks!
--
Best regards,
David Turner
I'm looking at the front page and I don't see what you're referring to; it
announces 1.6.4.
(meaning: thanks -- I just fixed it :-) )
On Mar 13, 2013, at 3:30 PM, David Turner wrote:
> Hi,
>
> On Feb 21, Jeff Squyres announced Open MPI 1.6.4. However,
> on the Open MPI home page, 1.6.3 is s
Dear Open MPI Pros
Which MPI data type corresponds to ptrdiff_t in C?
I guess the same question can be asked about size_t.
The FFTW3.3 MPI API has lots of stuff declared as
ptrdiff_t, and I need to pass them around with MPI,
hopefully without size or sign mistakes.
I am using Open MPI 1.6.3, if
MPI_Aint is always signed, as it is supposed to be able to hold any relative
difference between two memory locations. This it is a good match for ptrdiff_t.
There is no direct match for size_t, at least not directly exposed by the MPI
standard (using the MPI-2.2 POSIX types, e.g MPI_UINT64_T). M
Hi all,
I encountered an error when running openmpi Java applications (it works
fine with c/c++ applications). The java code compiles successfully, but it
crashed at runtime with:
NO LT_DLADVISE - CANNOT LOAD LIBOMPI
JAVA BINDINGS FAILED TO LOAD REQUIRED LIBRARIES
I think it has to do with dynam
13 matches
Mail list logo
