than can be used (e.g., number of on-node peers), that no additional
room is set aside for those FIFOs that will never be created. This
makes it easier to have dedicated FIFOs: just set btl_sm_num_fifos
to be very large rather than setting it to be the local number of
procs. In practice, we ask for extra headroom anyhow, so this change
generally won't matter.
This commit was SVN r22291.
Will need to be moved to v1.5 and v1.4. v1.4 will require a custom patch, but should apply cleanly to v1.5. CMRs to follow.
This commit was SVN r22289.
:-)
Okay, cleanup the prior commit so that the default component search path shows in ompi_info, and remains available in component_find.
This commit was SVN r22278.
issues with #2114 -- PGI v10.x should work fine now (even with the
"gfortran" executable name).
Fixes trac:2114.
This commit was SVN r22274.
The following SVN revision numbers were found above:
r22273 --> open-mpi/ompi@2e2a07e5eb
The following Trac tickets were found above:
Ticket 2114 --> https://svn.open-mpi.org/trac/ompi/ticket/2114
compiler.
Note that using the name "pgfortran" does not work -- you must still
use the names pgf77 and pgf90. LT has not yet been fully patched to
support the name "pgfortran". I advised PGI to take this issue up
with the Libtool guys.
There's still something wrong with the C++ support, however; I get
errors about a template directory switch when compiling the C++ MPI
bindings (doesn't happen with PGI 9.0). Still working on this... it
feels like it's still a Libtool issue because OMPI is not putting in
this compiler flag as far as I can tell:
{{{
/bin/sh ../../../libtool --tag=CXX --mode=link pgCC -g -version-info 0:0:0 -export-dynamic -o libmpi_cxx.la -rpath /home/jsquyres/bogus/lib mpicxx.lo intercepts.lo comm.lo datatype.lo win.lo file.lo ../../../ompi/libmpi.la -lnsl -lutil -lpthread
libtool: link: tpldir=Template.dir
libtool: link: rm -rf Template.dir
libtool: link: pgCC --prelink_objects --instantiation_dir Template.dir .libs/mpicxx.o .libs/intercepts.o .libs/comm.o .libs/datatype.o .libs/win.o .libs/file.o -Wl,--rpath -Wl,/users/jsquyres/svn/ompi-1.3/ompi/.libs -Wl,--rpath -Wl,/users/jsquyres/svn/ompi-1.3/orte/.libs -Wl,--rpath -Wl,/users/jsquyres/svn/ompi-1.3/opal/.libs -Wl,--rpath -Wl,/home/jsquyres/bogus/lib -L/users/jsquyres/svn/ompi-1.3/orte/.libs -L/users/jsquyres/svn/ompi-1.3/opal/.libs ../../../ompi/.libs/libmpi.so /users/jsquyres/svn/ompi-1.3/orte/.libs/libopen-rte.so /users/jsquyres/svn/ompi-1.3/opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lpthread
pgCC-Error-Unknown switch: --instantiation_dir
make: *** [libmpi_cxx.la] Error 1
}}}
Refs trac:2114.
This commit was SVN r22273.
The following Trac tickets were found above:
Ticket 2114 --> https://svn.open-mpi.org/trac/ompi/ticket/2114
"my_perfect_path":SYSTEM_DEFAULT:USER_DEFAULT
and OPAL will substitute its internally derived values for the defaults (instead of forcing the user to figure them out).
This commit was SVN r22272.
- removed tools/opari/doc/lacsi01.ps.gz which is equivalent to tools/opari/doc/lacsi01.pdf
- corrected svn:mime-type of tools/opari/doc/opari-logo-100.gif
This commit was SVN r22267.
friends also receive &argc and &argv (George asked Jeff to Ralph to
review before committing). The thought is that passing argv and argc
to opal/orte_init be useful to other projects outside of OMPI that are
using OPAL and/or ORTE (especially in conjunction with some other
bootstrapping code where it is helpful to modify argv). It's such a
small thing that it's easy to apply here to make others' lives a
little easier.
Ask George for more details; I'm just the messenger. :-)
Judging by the copyrights on this patch, it's been around for a
while. :-)
This commit was SVN r22260.
we should have also relaxed the error checking for MPI_GRAPH_CREATE.
Thanks to David Singleton for pointing this out.
This commit was SVN r22251.
The following SVN revision numbers were found above:
r21816 --> open-mpi/ompi@b8332ea2b2
Add orte configuration option to control the use of the framework in the system. Although the code will build, it will not be active unless configured with --enable-bootstrap.
If bootstrap is enabled and the new opal_sysinfo framework can successfully determine the cpu model, pass that info to the application as an MCA param to support some work at Sun.
Also, have daemons report back the resources they find to guide process mapping in bootstrap operations (i.e., where the daemon starts at node boot as opposed to being launched at application start).
Adjust some platform files to enable these capabilities.
This commit was SVN r22244.
other request-using frameworks.
- Rather than having mpi/c/* functions allocate requests explicitly,
pass the MPI_Request* down to the I/O component and have it
perform the allocation.
- While the I/O base provides a base request which can be used,
it is not required and all request management occurs within
the component.
- Push progress management into the component, rather than having it
happen in the base. Progress functions are now easily registered,
and not all (ie, the one existing) components use progress functions
in any rational way.
ROMIO switched to generalized requests instead of MPIO_Requests many
moons ago, and Open MPI now uses ROMIO's generalized requests, so there
is no reason to wrap those requests (which are OMPI requests) in another
level of request.
Now the file function passes the MPI_Request* to the ROMIO component,
which passes it to the underlying ROMIO function, which calls
MPI_Grequest_start to create an OMPI request, which is what gets set
as the request to the user. Much cleaner.
This patch has two motivations. One, a whole heck of a lot of code
just got removed, and request handling is now much cleaner for I/O
components. Two, by adding support for Argonne's proposed generalized
request extensions, we can allow ROMIO to provide async I/O through
generalized requests, which we couldn't rationally do in the old
setup due to the crazy request completion rules.
This commit was SVN r22235.
Modify the job_complete check so we don't kill jobs when a single proc was terminated by ORTE command via plm.terminate_procs
Still dies gracefully with a ctrl-c, and behaves as before when using plm.terminate_job
This commit was SVN r22227.
