Hi everyone,
I'm trying to state that a particular component depends on another
that should therefore be dlopened automatically when it is loaded. I
found some code doing exactly that in
mca_base_component_find:open_component, but can't find any example of
how to actually trigger that cod
This was the result of an unfortunate commit. Starting from revision
r20884 the header file ompi_config.h is not included anymore.
Thanks for the report.
george.
On Mar 25, 2009, at 13:29 , Kiril Dichev wrote:
One remark: after installation, I had to remove the '#include
"ompi_config.h"'
Hi All,
George - I really appreciate the quick response.
> Hi,
>
> at least for the specific test program I used, the negative values for
the peer attribute disappeared after George's modifications in 20844.
Same here for my profiling library - tested with openmpi-1.3.2a1r20855.
>
> One remark:
I did a quick check and I think there is no other possibility to get
the peer equal to -1. Well, at least in theory. Please let me know if
you find any other problems with our PERUSE interface.
Meanwhile, I will take a look at the peruse.h header.
Thanks,
george.
On Mar 25, 2009, at 1
Hi,
at least for the specific test program I used, the negative values for
the peer attribute disappeared after George's modifications in 20844.
One remark: after installation, I had to remove the '#include
"ompi_config.h"' line in the "include/peruse.h" header to get PERUSE
applications to comp
The answer is simple: the SLURM environmental variables when you set
SLURM_OVERCOMMIT=1 are telling us that only one slot/node is available
for your use. This is done by the SLURM_TASKS_PER_NODE envar.
So we can only launch 1 proc/node as this is all SLURM is allowing us
to do.
Ralph
On
Dear Support,
there is a problem with OpenMPI in version 1.3 and version 1.3.1 when
using our batch system Slurm. On our parallel computer there are 2
queues - one with exclusive usage of slots (cores) (SLURM_OVERCOMMIT=0)
within nodes and one without shared usage of slots (SLURM_OVERCOMMIT=1)
George -- correct me if I'm wrong -- we went through and audited ob1
and the relevant BTLs. The only places where WAIT remains are places
that are guaranteed to not be problematic.
So you shouldn't need to edit ob1 at all.
If you're working with Open MPI, you might want to investigate using
