Florent,
Long story short, yes, this is a known limitation.
btl/sm cannot be used for intra-nodes communications between processes from
different "jobs" (MPI_Comm_spawn() creates a new job),
so you will use the interconnect (if it allows it) or btl/tcp (assuming
pml/ob1 had been selected).
IIRC,
his difference in handling SIMD support
> between x86 and AArch64 in OpenMPI or am I wrong about the configuration
> process?
>
> Cheers,
>
> Marco
> On 31.01.25 11:47, Gilles Gouaillardet wrote:
>
> Marco,
>
> The compiler may vectorize if generating code optimised
Marco,
The compiler may vectorize if generating code optimised for a given
platform.
A distro provided Open MPI is likely to be optimised only for "common"
architectures (e.g. no AVX512 on x86 - SSE only? - and no SVE on aarch64)
Cheers,
Gilles
On Fri, Jan 31, 2025, 18:06 Marco Vogel wrote:
>
Florent,
All you need is to issue a Pull Request and make sure the commits are
signed off (and you understand the legal implications of doing that)
Cheers,
Gilles
On Wed, Jan 22, 2025, 19:28 'Florent GERMAIN' via Open MPI devel <
devel@lists.open-mpi.org> wrote:
> Hello,
> We are working on an
Folks,
Jeff Hammond and al. published "MPI Application Binary Interface
Standardization" las week
https://arxiv.org/abs/2308.11214
The paper reads the (C) ABI has already been prototyped natively in MPICH.
Is there any current interest into prototyping this ABI into Open MPI?
Cheers,
Gilles
cially said it is too old. Probably something worth filing a
> ticket for so that we can run to ground before 5.0 release. Oddly, CI
> continues to pass on RHEL7 in AWS. I'm not sure what we've done to cause
> that, but also worth investigating.
>
> Brian
>
> On 11
This is very odd ...
I dumped DISABLE_io_romio341, and it is *not* set (!)
Anyway, let's follow-up at https://github.com/open-mpi/ompi/issues/11088
Cheers,
Gilles
On Fri, Nov 18, 2022 at 5:37 PM Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:
> Let me ta
)
checking for MCA component io:romio341 compile mode... static
checking if want ROMIO component... yes
checking if MPI profiling is enabled... yes
*** Configuring ROMIO distribution
configure: OPAL configuring in 3rd-party/romio341
On Fri, Nov 18, 2022 at 5:18 PM Gilles Gouaillardet <
gilles.gouail
Folks,
I tried to build on a RHEL7 like, and it fails at make time because
ROMIO requires stdatomic.h
(it seems this file is only available from GCC 4.9)
Are we supposed to be able to build Open MPI 5 with GCC 4.8 (e.g. stock
RHEL7 compiler)?
--enable-mca-no-build=io-romio314 cannot hel
William,
What is the desired behavior if Open MPI built with CUDA is used on a
system where CUDA is not available or cannot be used because of ABI
compatibility issues?
- issue a warning (could not open the DSO because of unsatisfied
dependencies)?
- silently ignore the CUDA related components?
Hi,
Same impression here.
There are bug reports once in a while (both Open MPI mailing list and Stack
Overflow).
I remember one used the Java bindings to teach MPI.
So my gut feeling is the number of active users is small but not zero.
Cheers,
Gilles
On Wed, Aug 10, 2022 at 8:48 PM t-kawashim
n example would be great. Meanwhile, as you already
> have access to the root cause with a debugger, can you check what branch of
> the if regarding the communicator type in the
> ompi_coll_base_retain_datatypes_w function is taken. What is the
> communicator type ? Intra or in
Damian,
Thanks for the report!
could you please trim your program and share it so I can have a look?
Cheers,
Gilles
On Wed, May 4, 2022 at 10:27 PM Damian Marek via devel <
devel@lists.open-mpi.org> wrote:
> Hello,
>
> I have been getting intermittent memory corruptions and segmentation
> f
, then it's potentially worth the time.
>
> --
> Jeff Squyres
> jsquy...@cisco.com
>
> ________
> From: devel on behalf of Gilles
> Gouaillardet via devel
> Sent: Wednesday, March 23, 2022 10:28 PM
> To: Open MPI Developers
> C
Brian,
My 0.02 US$
Script based wrapper compilers are very useful when cross compiling,
so ideally, they should be maintained.
Cheers,
Gilles
On Thu, Mar 24, 2022 at 11:18 AM Barrett, Brian via devel <
devel@lists.open-mpi.org> wrote:
> Does anyone still use the script based wrapper compilers
Thomas,
in order to test Open MPI, you can download
https://raw.githubusercontent.com/open-mpi/ompi/master/examples/hello_c.c
and build it
$ mpicc -o hello_c examples/hello_c.c
and then run
$ mpiexec --mca btl ^openib -N 5 ./hello_c
It should display 5 different lines (rank 0 to 4 of 5).
If yo
Edgar and Jeff,
the root cause is we do not use pthreads here any more:
>From master config.log
configure:226861: gcc -std=gnu99 -o conftest -O3 -DNDEBUG
-finline-functions -fno-strict-aliasing -mcx16
-I/home/usersup/gilles/build/ompi-master/3rd-party/openpmix/include
-I/home/usersup/gilles/src/
Max,
Thanks for the report and suggesting a solution!
Could you please issue a pull request so your fix can be reviewed?
note the commit has to be signed-off (IANAL, make sure you understand
the implications)
in order to be accepted upstream.
Cheers,
Gilles
On Thu, Feb 4, 2021 at 6:40 AM Max S
Andrej,
that really looks like a SLURM issue that does not involve Open MPI
In order to confirm, you can
$ salloc -N 2 -n 2
/* and then from the allocation */
srun hostname
If this does not work, then this is a SLURM issue you have to fix.
Once fixed, I am confident Open MPI will just work
Che
; srun: error: task 0 launch failed: Unspecified error
> srun: error: task 3 launch failed: Unspecified error
> srun: error: task 2 launch failed: Unspecified error
> srun: error: task 1 launch failed: Unspecified error
> [terra:177267] [[5499,0],0] plm:slurm: primary daemons co
Andrej,
you *have* to invoke
mpirun --mca plm slurm ...
from a SLURM allocation, and SLURM_* environment variables should have
been set by SLURM
(otherwise, this is a SLURM error out of the scope of Open MPI).
Here is what you can try (and send the logs if that fails)
$ salloc -N 4 -n 384
and on
Andrej,
I can reproduce this behavior ... when running outside of a slurm allocation.
What does
$ env | grep ^SLURM_
reports?
Cheers,
Gilles
On Tue, Feb 2, 2021 at 9:06 AM Andrej Prsa via devel
wrote:
>
> Hi Ralph, Gilles,
>
> > I fail to understand why you continue to think that PMI has anyt
Andrej,
My previous email listed other things to try
Cheers,
Gilles
Sent from my iPod
> On Feb 2, 2021, at 6:23, Andrej Prsa via devel
> wrote:
>
> The saga continues.
>
> I managed to build slurm with pmix by first patching slurm using this patch
> and manually building the plugin:
>
>
Andrej,
you are now invoking mpirun from a slurm allocation, right?
you can try this:
/usr/local/bin/mpirun -mca plm slurm -np 384 -H
node15:96,node16:96,node17:96,node18:96
python testmpi.py
if it does not work, you can collect more relevant logs with
mpirun -mca plm slurm -mca plm_base_verbo
Andrej,
that's odd, there should be a mca_pmix_pmix3x.so (assuming you built
with the internal pmix)
what was your exact configure command line?
fwiw, in your build tree, there should be a
opal/mca/pmix/pmix3x/.libs/mca_pmix_pmix3x.so
if it's there, try running
sudo make install
once more and se
Andrej,
it seems only flux is a PMIx option, which is very suspicious.
can you check other components are available?
ls -l /usr/local/lib/openmpi/mca_pmix_*.so
will list them.
Cheers,
Gilles
On Mon, Feb 1, 2021 at 10:53 PM Andrej Prsa via devel
wrote:
>
> Hi Gilles,
>
> > what is your mpiru
Andrej,
what is your mpirun command line?
is mpirun invoked from a batch allocation?
in order to get some more debug info, you can
mpirun --mca ess_base_verbose 10 --mca pmix_base_verbose 10 ...
Cheers,
Gilles
On Mon, Feb 1, 2021 at 10:27 PM Andrej Prsa via devel
wrote:
>
> Hi Gilles,
>
> >
Andrej,
The log you just posted strongly suggests a previously built (without
--enable-debug) internal PMIx is being used.
I invite you to do some cleanup
sudo rm -rf /usr/local/lib/openmpi /usr/local/lib/pmix
and then
sudo make install
and try again.
if the issue persists, please post the outpu
* built with this option.
That means, that by default, mca_pml_ucx.so and friends will get
libuc?.so libraries at runtime from rpath
(and that cannot be overridden by LD_LIBRARY_PATH).
Cheers,
Gilles
On 1/28/2021 12:52 AM, Jeff Squyres (jsquyres) wrote:
On Jan 27, 2021, at 2:00 AM, Gilles
n MPI configure script already has overrides for
ucx_CFLAGS, ucx_LIBS, and ucx_STATIC_LIBS, but nothing for something
like "ucx_LDFLAGS=''".
I didn't see a simple way to add support for such an override without
some more extensive changes to multiple m4 files.
On Sun, J
Tim,
Have you tried using LD_LIBRARY_PATH?
I guess "hardcoding the full path" means "link with -rpath", and IIRC,
LD_LIBRARY_PATH
overrides this setting.
If this does not work, here something you can try (disclaimer: I did not)
export LD_LIBRARY_PATH=/same/install/prefix/ucx/1.9.0/lib
configure
Hi Jeff,
On RHEL 8.x, the default gcc compiler is 8.3.1, so I think it is worth testing.
Containers could be used to setup a RHEL 8.x environment (so not only
gcc but also third party libs such as libevent and hwloc can be used)
if the MTT cluster will not shrink bigger.
Cheers,
Gilles
On Fri,
Luis,
a MPI window creation is a collective operation, that involves the
creation of a communicator that involves (several) non blocking
allgather.
I recommend you first make sure you that creating a windows does not
start a recursion.
Cheers,
Gilles
On Fri, May 22, 2020 at 7:53 PM Luis Cebam
Luis,
you can do this:
struct ompi_info_t * info = &ompi_mpi_info_null.info;
ret = ompi_win_create_dynamic(&info_null->super, comm, win);
Cheers,
Gilles
On Fri, May 15, 2020 at 7:38 PM Luis via devel wrote:
>
> Hi OMPI devs,
>
> I was wondewring if this warning is expected, if not, how should
John,
OMPI_LAZY_WAIT_FOR_COMPLETION(active)
is a simple loop that periodically checks the (volatile) "active"
condition, that is expected to be updated by an other thread.
So if you set your breakpoint too early, and **all** threads are stopped
when this breakpoint is hit, you might experienc
Folks,
-L/path/to/lib -lfoo will look for the foo library (libfoo.so or
libfoo.a on Linux) in the /path/to/lib directory.
In the case of a dynamic library (e.g. libfoo.so), its dependencies will
*not* be searched in /path/to/lib
(and this is where LD_LIBRARY_PATH helps)
that can be evide
Jeff,
I agree we are not trying to run the binary here, but I am still puzzled here...
Basically,
gcc -o a.out foo.o -L/.../hcoll/lib -lhcoll
and libhcoll.so depends on libsharp.so (that is in /.../sharp/lib)
1) do you expect this to just work even if the linker has no idea where to find
libs
Chris,
I would try to add the directory containing libsharp in your LD_LIBRARY_PATH
Cheers,
Gilles
On October 15, 2019, at 11:08 PM, Chris Ward via devel
wrote:
Adding an appropriate LDFLAGS= didn't help; the revised tarball is here
http://tjcw.freeshell.org/ompi-output-2.tar.bz2 . Do I nee
Lawrence,
My apologies for the incorrect link.
The patch is at https://github.com/open-mpi/ompi/pull/6672.patch
Cheers,
Gilles
On Sat, Jul 6, 2019 at 12:21 PM Gilles Gouaillardet
wrote:
>
> Lawrence,
>
> this is a known issue (--cpu_bind optioned was removed from SLURM in
> fav
Lawrence,
this is a known issue (--cpu_bind optioned was removed from SLURM in
favor of the --cpu-bind option) and the fix will be available in Open
MPI 4.0.1
Meanwhile, you can manually download and apply the patch at
https://github.com/open-mpi/ompi/pull/6445.patch or use a nightly
build of the
Hi Chris,
This is supported (but lightly tested)
You should grep OPAL_ENABLE_HETEROGENEOUS_SUPPORT instead.
All you need is to configure --enable-heterogeneous ...
Cheers,
Gilles
Sent from my iPod
> On May 14, 2019, at 19:12, Chris Ward via devel
> wrote:
>
> OMPI_ENABLE_HETEROGENEOUS_SUP
Folks,
FYI, and as posted by Damian Rouson in the de...@mpich.org ML
The upcoming GCC 9 release will contain the first version of gfortran
that provides the Fortran 2018 ISO_Fortran_binding.h header file,
which MPICH requires in order to build MPI 3's mpi_f08 module. If
anyone is intereste
Marcin,
Based on your description, you might want to investigate non blocking
collectives (e.g. MPI_Ibcast) or even upcoming persistent collectives
(e.g. MPIX_Bcast_init).
If you know the address of the receive buffer, then you can MPI_Ibcast()
on non root ranks very early, and then MPI_Tes
Folks,
The rml/ofi component has been removed from master.
Then common/ofi was later removed from master and mtl/ofi configury
component was revamped not to depend on common/ofi configury stuff.
Only the latter change was backported to the release branches.
The issue is that rml/ofi is stil
n but the root cause
is how we use travis.
Cheers,
Gilles
On 1/9/2019 11:45 AM, Gilles Gouaillardet wrote:
I do not know how/why travis was enabled.
That being said, the errors look legit to me, and there are two
1) with clang 5.0
CC opal_convertor_raw.lo
In file included from opal
I do not know how/why travis was enabled.
That being said, the errors look legit to me, and there are two
1) with clang 5.0
CC opal_convertor_raw.lo
In file included from opal_convertor_raw.c:21:
In file included from ../../opal/datatype/opal_convertor_internal.h:21:
In file included
Nathan,
I inadvertently noted that btl/uct has the highest exclusivity and
consider all procs are reachable.
As a consequence :
- btl/uct is used in altogether with btl/vader for intra-node
communications
- btl/uct is used altogether with btl/self for self communications
This behaviou
Chris,
I am a bit puzzled at your logs.
As far as I understand,
ldd libhhgttg.so.1
reports that libopen-rte.so.40 and libopen-pal.so.40 are both
dependencies, but that does not say anything on
who is depending on them. They could be directly needed by
libhhgttg.so.1 (I hope / do not think it is
org.au>> wrote:
HI Gilles,
On 2 Nov 2018, at 11:03 am, Gilles Gouaillardet <mailto:gil...@rist.or.jp>> wrote:
I noted the stack traces refers opal_cuda_memcpy(). Is this issue
specific to CUDA environments ?
No, this is just on normal CPU-only nodes. But memcpy always goes
thr
Hi Ben,
I noted the stack traces refers opal_cuda_memcpy(). Is this issue
specific to CUDA environments ?
The coll/tuned default collective module is known not to work when tasks
use matching but different signatures.
For example, one task sends one vector of N elements, and the other tas
rch path for headers
>(stat.h is found).
>
>On the other hand, statfs.h is not found, as if /usr/include were not in the
>search path for headers.
>
>
>If I try
>
>
>export CPATH=/usr/include
>
>export C_INCLUDE_PATH=/usr/include
>
>export CPLUS_INCLUDE_PAT
n Mon, Oct 22, 2018 at 5:26 AM Gilles Gouaillardet <mailto:gil...@rist.or.jp>> wrote:
Santiago,
the config.log reports there is no /usr/include/sys/statfs.h on
your system.
on my system, this file exists and is provided by the
msys2-runtime-devel file,
so the f
Santiago,
the config.log reports there is no /usr/include/sys/statfs.h on your system.
on my system, this file exists and is provided by the
msys2-runtime-devel file,
so the first steps are to check this package is installed and if not,
install it.
note I ran pacman -Syu a few times to m
Stephan,
Have you already checked https://github.com/pmix/prrte ?
This is the PMIx Reference RunTime Environment (PPRTE), which was built
on top of orted.
Long story short, it deploys the PMIx server and then you start your MPI
app with prun
An example is available at
https://github.com/p
Folks,
When running a simple helloworld program on OS X, we can end up with the
following error message
A system call failed during shared memory initialization that should
not have. It is likely that your MPI job will now either abort or
experience performance degradation.
Local host:
IIRC mtt-relay is not only a proxy (squid can do that too).
mtt results can be manually copied from a cluster behind a firewall, and
then mtt-relay can “upload” these results to mtt.open-MPI.org
My 0.02US$
Gilles
On Saturday, September 15, 2018, Jeff Squyres (jsquyres) via devel <
devel@lists.op
:46 AM Jeff Squyres (jsquyres) via devel
wrote:
>
> On Jul 17, 2018, at 8:49 PM, Gilles Gouaillardet wrote:
> >
> > I noted the internal Fortran bindings (e.g. [p]ompi_barrier_f and friends)
> > are defined in the user facing mpi_f08.mod.
> >
> > My impressions a
Jeff,
When working on https://github.com/open-mpi/ompi/pull/5430,
I noted the internal Fortran bindings (e.g. [p]ompi_barrier_f and
friends) are defined in the
user facing mpi_f08.mod.
My impressions are :
1. pompi_barrier_f and friends are never used (e.g. pbarrier_f08.F90
calls ompi_b
I was unable to reproduce this on Ubuntu 14.04.5
Note the default gcc is 4.8
gcc-4.9 can be installed, but no g++ nor gfortran.
Did you build Open MPI with the same compiler used to build libUtils.so and
a.out
What do
type gcc
ls -l /usr/bin/gcc
gcc —version
g++ —version
say ?
On top of the info
uyres)
> > Subject: Re: [OMPI devel] Shared object dependencies
> >
> > How is it that Edgar is not running into these issues?
> >
> > Edgar: are you compiling with --disable-dlopen, perchance?
> >
> >
> > > On Jun 12, 2018, at 6:04 AM, Gilles
h->f_set_aggregator_props), and the same with the mca parmaeters, we
> access them through a function that is stored as a function pointer on the
> file handle structure.
>
> Thanks
> Edgar
>
>
> > -----Original Message-
> > From: devel [mailto:devel-boun...@li
Tyson,
thanks for taking the time to do some more tests.
This is really a bug in Open MPI, and unlike what I thought earlier,
there are still
some abstraction violations here and there related to ompio.
I filed https://github.com/open-mpi/ompi/pull/5263 in order to address them
Meanwhil
Edgar,
I checked the various release branches, and I think this issue was
fixed by
https://github.com/open-mpi/ompi/commit/ccf76b779130e065de326f71fe6bac868c565300
This was back-ported into the v3.0.x branch, and that was before the
v3.1.x branch was created.
This has *not* been backported into
Nathan,
there could be another issue :
with gcc 8.1.0, I get some warnings (see logs at the end)
From
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-error-function-attribute
error ("message")warning ("message")
If the error or warning attribute is used on a function
Marco,
Have you tried to build Open MPI with an external (e.g. Cygwin provided)
libevent library ?
If that works, I think that would be the preferred method.
Cheers,
Gilles
On Wednesday, May 23, 2018, Marco Atzeri wrote:
> The attached patch allows the compilation of openmpi-3.1.0
> on cygwin
0? I mean, we went 6 months without it working
>> and no one cared. We can’t fix all bugs, and I’m a little concerned about
>> making changes right before release.
>>
>> Brian
>>
>>> On Apr 17, 2018, at 7:49 AM, Gilles Gouaillardet
>>> wrote
Brian,
https://github.com/open-mpi/ompi/pull/5081 fixes support for external PMIx v2.0
Support for external PMIx v1 is broken (same in master) and extra dev would be
required to fix it.
The easiest path, if acceptable, is to simply drop support for PMIx v1
Cheers,
Gilles
"Barrett, Brian vi
Bryce,
The current status on OS X is half baked, the /usr/bin/javah symlink
is still there, but it points to nothing,
and a direct consequence is that AC_PATH_PROG detects /usr/bin/javah,
when I hope it does not.
Since javac -h is already working in Java 8, I guess we do not care of
older java v
Hi Rong,
SSH is safe when properly implemented. That being said, some sites
does not allow endusers to directly SSH into compute nodes because
they do not want them to do anything without the resource manager
knowing about it. What is your concern with SSH ?
You can run a resource manager (such a
Folks,
At SC'17 Open MPI BoF, we presented slice 74 about cross-version
mpirun interoperability (i attached a screenshot for your
convenience).
The topic is documented on the wiki at
https://github.com/open-mpi/ompi/wiki/Container-Versioning.
If I oversimplify, we have two use-cases to consider
d maintain.
Cheers,
Gilles
On Thu, Feb 1, 2018 at 3:44 AM, Barrett, Brian via devel
wrote:
>
>> On Jan 31, 2018, at 8:33 AM, r...@open-mpi.org wrote:
>>
>>
>>
>>> On Jan 31, 2018, at 7:36 AM, Jeff Squyres (jsquyres)
>>> wrote:
>>>
&
Folks,
I tried to push some trivial commits directly to the master branch and
was surprised that is no more allowed.
The error message is not crystal clear, but I guess the root cause is
the two newly required checks (Commit email checker and
Signed-off-by-checker) were not performed.
As a kind
nt hooks provided using patcher/overwrite,
> leave pinned can give incorrect results.
>
> -Paul
>
> On Tue, Jan 23, 2018 at 9:17 PM, Gilles Gouaillardet
> wrote:
>>
>> Dave,
>>
>> here is what I found
>>
>> - MPI_THREAD_MULTIPLE is not part of the equ
d, Jan 24, 2018 at 1:29 PM, Gilles Gouaillardet
wrote:
> Dave,
>
> i can reproduce the issue with btl/openib and the IMB benchmark, that
> is known to MPI_Init_thread(MPI_THREAD_MULTIPLE)
>
> note performance is ok with OSU benchmark that does not require
> MPI_THREAD_MULTIP
Dave,
i can reproduce the issue with btl/openib and the IMB benchmark, that
is known to MPI_Init_thread(MPI_THREAD_MULTIPLE)
note performance is ok with OSU benchmark that does not require
MPI_THREAD_MULTIPLE
Cheers,
Gilles
On Wed, Jan 24, 2018 at 1:16 PM, Gilles Gouaillardet wrote:
> D
Dave,
one more question, are you running the openib/btl ? or other libraries
such as MXM or UCX ?
Cheers,
Gilles
On 1/24/2018 12:55 PM, Dave Turner wrote:
We compiled OpenMPI 2.1.1 using the EasyBuild configuration
for CentOS as below and tested on Mellanox QDR hardware.
./configur
Dave,
At first glance, that looks pretty odd, and I'll have a look at it.
Which benchmark are you using to measure the bandwidth ?
Does your benchmark MPI_Init_thread(MPI_THREAD_MULTIPLE) ?
Have you tried without --enable-mpi-thread-multiple ?
Cheers,
Gilles
On Wed, Jan 24, 2018 at 12:55 PM,
33 PM, Josh Hursey wrote:
We (IBM) are interested in maintaining support for ROMIO in Open MPI.
We are investigating upgrading the ROMIO version inside Open MPI, but
I have no ETA on when that work will be complete/available.
On Wed, Nov 8, 2017 at 4:37 AM, Gilles Gouaillardet
mailto:gilles.goua
Farouk,
as far as i am concerned, there is no plan to stop supporting ROMIO.
that being said, i am not aware there are any plans to upgrade to the
latest ROMIO in a near future.
Also, please note ROMIO is the default module when the Lustre
filesystem is used.
Cheers,
Gilles
On Wed, Nov 8, 2017
vanilla Open MPI has no support for the tofu interconnect, nor Fujitsu
batch manager.
also, and iirc, tcp communication between two compute nodes is not
always possible on the K computer.
so the simple answer is no.
Cheers,
Gilles
On 11/8/2017 10:37 AM, Christopher Samuel wrote:
On 08
gt;> (requires local.mk build operators.flux.c instead of operators.fv4.c) and
>>> they are a couple commits behind. Regardless, this issue has persisted on K
>>> for several years. By default, it will build log(N) subcommunicators where
>>> N is the problem size.
Samuel,
The default MPI library on the K computer is Fujitsu MPI, and yes, it
is based on Open MPI.
/* fwiw, an alternative is RIKEN MPI, and it is MPICH based */
>From a support perspective, this should be reported to the HPCI
helpdesk http://www.hpci-office.jp/pages/e_support
As far as i unders
Chris,
feel free to issue a PR, or fully describe the issue so a developer
can update the FAQ accordingly.
Cheers,
Gilles
On Sat, Nov 4, 2017 at 4:44 PM, Chris Samuel wrote:
> Hi folks,
>
> I was looking to file an issue against the website for the FAQ about XRC
> support (given it was disable
Marco,
can you please give the attached patch a try ?
so far, it compiles for me.
btw, i faced some issues (conflicting definitions between windows.h and
netdb.h),
did you need some patches in order to solve these issues ?
Cheers,
Gilles
On 10/31/2017 1:25 AM, Marco Atzeri wrote:
p
George,
since this is an automatically generated file (at configure time), this
is likely a packaging issue in upstream PMIx
i made https://github.com/pmix/pmix/pull/567 in order to fix that.
fwiw, nightly tarballs for v3.0.x, v3.1.x and master are affected
Cheers,
Gilles
On 10/23/201
ted to 1.10.x?
>
>Best
>Paul Kapinos
>
>
>
>
>On 10/12/2017 09:31 AM, Gilles Gouaillardet wrote:
>> Paul,
>>
>>
>> i made PR #4331 https://github.com/open-mpi/ompi/pull/4431 in order to
>> implement
>> this.
>>
>
Paul,
i made PR #4331 https://github.com/open-mpi/ompi/pull/4431 in order to
implement this.
in order to enable passive wait, you simply need to
mpirun --mca mpi_poll_when_idle true ...
fwiw, when you use mpi_yield_when_idle, Open MPI does (highly
oversimplified)
for (...) sched_yield()
Phil,
Did you simply try `--with-pmi` ?
According to the configury macros, we look for /usr/include/pmi.h and then
/usr/include/slurm/pmi.h, so that should work just fine.
If not, can you please compress and post your config.log ?
Cheers,
Gilles
Phil K via devel wrote:
>Exactly. Sorry if m
Marco,
can you please detail how you built Open MPI ?
i guess you downloaded a tarball and built from that.
in this case, there is no need to run
autogen.pl --force
and unless something is wrong with the timestamps of the tarball,
autoreconf should never be invoked.
Cheers,
Gilles
On Sat, Se
Howard,
i faced the same issue after a MPSS (Intel software stack for many core) update.
as Brice explained, the issue comes from the embedded (and older)
hwloc does understand the file format
written by MPSS (more recent) hwloc.
i simply rebuilt Open MPI with the external hwloc provided by MPSS
Phil,
In previous versions of Open MPI, the Fortran bindings were calling
the related C MPI_* subroutine, that could be wrapped in C.
Now, Fortran bindings directly invoke the C PMPI_* subroutine, and
hence it cannot be wrapped in C.
The solution is to wrap C subroutines in C, and to wrap Fortran
Samuel,
fwiw, the issue is fixed in upcoming Open MPI 3.0
Cheers,
Gilles
On Wed, Jul 26, 2017 at 3:43 AM, Samuel Poncé wrote:
> Dear OpenMPI developpers,
>
> I would like to report a bug for openmpi/2.0.2
>
> This bug might have been corrected in earlier version. Appologies if it is
> the case
Hi,
you meant Open MPI 1.8.2, right ?
as far as i am concerned, i always configure Open MPI with
--enable-mpirun-prefix-by-default, so i do not need to set
LD_LIBRARY_PATH in my .bashrc
if you want us to investigate this issue, please post the full error message
- is the issue reported by mpiru
to base our bots (vs. the existing
> signed-off-by-checker and email checker that are custom written by me).
>
> Something to look into...
>
>
>> On Jul 13, 2017, at 12:21 AM, Gilles Gouaillardet wrote:
>>
>> Thanks Jeff,
>>
>>
>> one more improv
Thanks Jeff,
one more improvement : could you please have the bot also ignore revert
commits ?
Cheers,
Gilles
On 7/7/2017 11:56 PM, Jeff Squyres (jsquyres) wrote:
FYI: the "signed-off-by-checker" CI on Github now ignores merge commits
(because those usually aren't signed -- e.g., if yo
Josh and all,
an other or complementary idea is to use MTT from jenkins and with the
junit plugin.
iirc, the python client can generate a junit xml report, and fwiw, i
made a simplistic proof of concept in the perl client.
the idea is the junit jenkins plugins display a summary of all tests
(ok, k
Thanks Paul,
i made https://github.com/open-mpi/ompi/pull/3802 to fix this issue.
once it completes CI, i will merge and PR vs the release branches
Cheers,
Gilles
On 7/4/2017 8:19 AM, Paul Hargrove wrote:
Below is the corresponding failure at build time (rather than link
time) for "clang
Thanks Philipp,
You can open a Pull Request vs the master branch on the github repository
https://github.com/open-mpi/ompi.git
All you need is sign-off your commits (please make sure you understand what it
means)
Then one of us will backport it to the release branches once it gets merged.
Cheer
Ralph,
my 0.02 US$
i noted the error message mentions 'holding lock
"pmix_mutex_t.m_lock_pthread"', but it does not explicitly mentions
'pmix_global_lock' (!)
at line 446, PMIX_WAIT_THREAD() does release 'cb.lock', which has the
same type than 'pmix_global_lock', but is not the very same
Ralph,
in your environment, pml/monitoring is disabled.
so instead of displaying "MCA pml monitoring", ompi_info --all displays
"MCA (disabled) pml monitoring" which is larger than 24 characters.
fwiw, you can observe the same behavior with
OMPI_MCA_sharedfp=^lockedfile ompi_info --all
on
1 - 100 of 820 matches
Mail list logo
