case of:
sizeof(MPI_Flogical) != sizeof (int)
and
Fortran value of .TRUE. != 1
as is often the case.
- Check in configure the value of .TRUE., the C-type coresponding to
logical and check, that fortran compiler does not do something strange
with arrays of logicals
- Convert all occurrences of logicals in the fortran wrappers, only
in case it is needed.
*Please note* Implementation of MPI_Cart_sub needed special treatment.
- Output these value in ompi_info -a
- Clean up the prototypes_mpi.h to just have a single definition and
thereby deleting the necessity for prototypes_pmpi.h
- configured, compiled and tested with F90-program, which uses
MPI_Cart_create and MPI_Cart_get:
linux ia32, gcc (no testing, as no f90)
linux ia32, gcc --disable-mpi-f77 --disable-mpi-f90 (had a bug there)
linux ia32, icc-8.1
linux opteron, gcc-3.3.5, pgcc, pathccx/pathf90 (tested just
pgi-compiler)
linux em64t, gcc, icc-8.1 (tested just icc)
This commit was SVN r8254.
increase the previous connection code was broken. It can take as much as 60 seconds to connect
64 processes. Now we do not create the connections when we add the procs but only when we send
them the first message. Now it take only 1.6 seconds to setup a 64 procs MPI job over MX (doing a 2 steps barrier in order to insure that we create all the connections).
This commit was SVN r8252.
displacement (for both the inter and intra-communicator version). The
displacements in scatterv are given in multiples of the sendtype.
This fix should probably make to v1.0.1 as well?
This commit was SVN r8251.
argument is defined to be
integer (KIND=MPI_ADDRESS_KIND)
we have to map that to an MPI_Aint in the f->c interface, else the
typecast back from the C to the Fortran interface will be wrong as well.
The same holds (at least) for all other new MPI-2 datatype functions
which take a byte-displacement or an address as an argument.
This commit was SVN r8243.
Thanks to Anthony Chan for pointing this out.
Note that these will only work for the Fortran compiler that Open MPI
was configured with -- since these values, are, by definition,
single-value, they cannot support all 4 values that Open MPI may
generate for the different Fortran name-mangling schemes. A lengthy
comment in ompi_mpi_init.c explains this in more detail. Added to the
README to explain this situation, as well as the forthcoming
.TRUE. Fortran fixes.
This commit was SVN r8231.
* turns out (duh!) that there was a reason that the <projectdir>dir
variable was set in the AM conditional. If not, stupid directories
are created and not needed... duh.
This commit was SVN r8205.
component/base Makefile.am files, reducing the time configure spends
stamping out Makefiles at the end
* Install base_impl.h file when devel-headers are being installed
This commit was SVN r8200.
- Separate out the registration of the MCA params into a standalong
function that is invoked by ompi_mpi_init() (so that ompi_info can
see these params)
- Rename the params to "mpi_ddt_*" instead of "datatype_*" so that
they fit into the common naming scheme
This commit was SVN r8196.
do for mpirun/orterun. This will allow -mca btl foo,self to work as
expected when doing MPI_COMM_SPAWN and friends.
This should be pushed to the v1.0 branch
This commit was SVN r8170.
is labeled as internal so the users will not see it but it is not read-only so we can still
play with it (that's for our internal tests). This is supposed to dissapear later after the
next (or next next) release of the MX library, but we need it now as a quick fix before the
release.
This commit was SVN r8161.
Remove the old function from the dt_unpack.c and activate the new one from dt_copy.c
Add a MCA param ompi_copy_debug to get messages about the local memory copies in the new function.
Slightly change the prototype of the function to keep the compilers happy on some platforms.
This commit was SVN r8142.
- remove dead code that isn't used anywhere (originally ompi_fifo_t
was going to be a generalized class, but now it's exclusively used
in the sm stuff, so there's no point in the generalized code that
definitely *won't* work with the sm btl, or is not being used now
[SVN always has history so we can go back])
- had to add an interprocess lock in the area where the writer may
create a new circular buffer to ensure that the reader's tail
doesn't accidentally end up back in the same old buffer while the
head continues on to a new circular buffer (this was what was
happening to cause some intel tests to hang -- e.g., MPI_Scan_c,
MPI_Send_fairness_c and MPI_Isend_fairness_c). Unbelievably, this
may actually *increase* performance because it may order things
better. Will do performance testing tomorrow. We're fairly certain
that this lock can probably be removed and the code fixed in a
different way, but we're under a deadline and correctness comes
first, so it's been added to the to-do list to come back and
re-examine this case later.
This commit was SVN r8136.
- Add big comment about a general overview of what the sm btl is doing
- random small code cleanups
- fix instances of mca_btl_sm[0] to mca_btl_sm[1] where relevant
- remove a lot of unused, confusing, and incorrect interface functions
from ompi_fifo.h and ompi_circular_buffer.h. These functions, if
they were used, would not work properly with the scheme that the sm
btl uses with the fifos (i.e., receiver makes right -- if necessary)
- add some missing offset computations in the fifo and circular buffers
- change the types of offsets to be ssize_t, not size_t
- remove an offset parameter from a function that didn't need it
This commit was SVN r8135.
- Ensure to convert base_shared_mem_flags to be a relative offset in
the global storage, and then to convert that back to an absolute
virtual address before we try to use it
- Don't double increment n_local_procs when calculating the peer rank
during bootstrapping of the different base address case
Something else is still wrong; if mmap() returns a different base
address, things don't work (i.e., segv or hang forever when you try to
send a message). More specifically, the bootstrapping now seems to
correctly handle the case when mmap() base addresses are different,
but the message passing does *not* -- it always assumes that the
mmap() base addresses are the same.
Still working on the fix for that -- want to checkpoint what has been
done so far to facilitate working on different machines...
This commit was SVN r8134.
