On 23 May 9:37PM, Jonathan Dursi wrote:
On the other hand, it works everywhere if I pad the rcounts array with
an extra valid value (0 or 1, or for that matter 783), or replace the
allgatherv with an allgather.
.. and it fails with 7 even where it worked (but succeeds with 8) if I
pad
In case it is helpful to those who may not have the Intel compilers, these
are the libraries against which the two executables of Lisandro's
allgather.c get linked:
with Intel compilers:
=
$ ldd a.out
Fails for me with 1.4.3 with gcc, but works with intel; works with 1.4.4
with gcc or intel; fails with 1.5.5 with either. Succeeds with intelmpi.
On the other hand, it works everywhere if I pad the rcounts array with
an extra valid value (0 or 1, or for that matter 783), or replace the
On Wed, 23 May 2012, Lisandro Dalcin wrote:
On 23 May 2012 19:04, Jeff Squyres wrote:
Thanks for all the info!
But still, can we get a copy of the test in C? That would make it
significantly easier for us to tell if there is a problem with Open MPI --
mainly because we
On May 23, 2012, at 6:20 PM, marco atzeri wrote:
> ~ 90% of the time we have mismatch problems between upstream and
> cygwin on autoconf/automake/libtool versions that are not cygwin
> aware or updated.
Ok, fair enough.
I'd be curious if you actually need to do this with Open MPI -- we use very
On 5/23/2012 11:20 PM, Jeff Squyres wrote:
On May 23, 2012, at 9:53 AM, marco atzeri wrote:
experience says that autoreconf is a good approach on cygwin,
it is almost standard on our package build procedure.
I'm still curious: why? (I'm *assuming* that you're building from an official
Open
Thanks for all the info!
But still, can we get a copy of the test in C? That would make it
significantly easier for us to tell if there is a problem with Open MPI --
mainly because we don't know anything about the internals of mpi4py.
On May 23, 2012, at 5:43 PM, Bennet Fauber wrote:
>
Jeff,
Well, not really, since the test is written in python ;-)
The mpi4py source code is at
http://code.google.com/p/mpi4py/downloads/list
but I'm not sure what else I can provide, though.
I'm more the reporting middleman here. I'd be happy to try to connect you
and the
Thanks, Ralph,
On Wed, 23 May 2012, Ralph Castain wrote:
I don't honestly think many of us have any knowledge of mpi4py. Does
this test work with other MPIs?
The mpi4py developers have said they've never seen this using mpich2. I
have not been able to test that myself.
MPI_Allgather
Can you provide us with a C version of the test?
On May 23, 2012, at 4:52 PM, Bennet Fauber wrote:
> I've installed the latest mpi4py-1.3 on several systems, and there is a
> repeated bug when running
>
> $ mpirun -np 5 python test/runtests.py
>
> where it throws an error on mpigather
On May 23, 2012, at 9:53 AM, marco atzeri wrote:
> experience says that autoreconf is a good approach on cygwin,
> it is almost standard on our package build procedure.
I'm still curious: why? (I'm *assuming* that you're building from an official
Open MPI tarball -- is that incorrect?)
I ask
I don't honestly think many of us have any knowledge of mpi4py. Does this test
work with other MPIs?
MPI_Allgather seems to be passing our tests, so I suspect it is something in
the binding. If you can provide the actual test, I'm willing to take a look at
it.
On May 23, 2012, at 2:52 PM,
I've installed the latest mpi4py-1.3 on several systems, and there is a
repeated bug when running
$ mpirun -np 5 python test/runtests.py
where it throws an error on mpigather with openmpi-1.4.4 and hangs with
openmpi-1.3.
It runs to completion and passes all tests when run with -np
On 5/23/2012 2:08 PM, Ralph Castain wrote:
Add "libompitrace" to your enable-contrib-no-build list. There is likely a
missing include in there, but you don't need that lib to run. We'll take a look at it.
thanks.
build was fine and check passed almost all
from "grep -i pass
On 05/23/2012 03:05 PM, Jeff Squyres wrote:
On May 23, 2012, at 6:05 AM, Simone Pellegrini wrote:
If process A sends a message to process B and the eager protocol is used then I
assume that the message is written into a shared memory area and picked up by
the receiver when the receive
On May 23, 2012, at 7:05 AM, Jeff Squyres wrote:
> On May 23, 2012, at 6:05 AM, Simone Pellegrini wrote:
>
>>> If process A sends a message to process B and the eager protocol is used
>>> then I assume that the message is written into a shared memory area and
>>> picked up by the receiver
On 5/23/2012 3:19 PM, Jeff Squyres (jsquyres) wrote:
Just curious - are you running autogen for any particular reason?
I don't know how much Cygwin testing we've done.
Sent from my phone. No type good.
experience says that autoreconf is a good approach on cygwin,
it is almost standard on
On 5/22/12 10:36 PM, "Orion Poplawski" wrote:
>On 05/22/2012 10:34 PM, Orion Poplawski wrote:
>> On 05/21/2012 06:15 PM, Jeff Squyres wrote:
>>> On May 15, 2012, at 10:37 AM, Orion Poplawski wrote:
>>>
$ mpicc -showme:link
-pthread -m64 -L/usr/lib64/openmpi/lib
Just curious - are you running autogen for any particular reason?
I don't know how much Cygwin testing we've done.
Sent from my phone. No type good.
On May 23, 2012, at 6:09 AM, "Ralph Castain" wrote:
> Add "libompitrace" to your enable-contrib-no-build list. There is
On May 23, 2012, at 6:05 AM, Simone Pellegrini wrote:
>> If process A sends a message to process B and the eager protocol is used
>> then I assume that the message is written into a shared memory area and
>> picked up by the receiver when the receive operation is posted.
Open MPI has a few
Hello,
I have built openmpi-1.6 for MacOSX Lion 10.7.4 with intel compilers v12.1
(icc,icpc,ifort)
When I try to install the mpif90 wrapper, I have the error message : ifort:
error #10104: unable to open '-commons'
When I compare "mpif90 -showme" from version 1.5.4 and version 1.6, I find :
Add "libompitrace" to your enable-contrib-no-build list. There is likely a
missing include in there, but you don't need that lib to run. We'll take a look
at it.
On May 23, 2012, at 12:58 AM, marco atzeri wrote:
> I am trying to build openmpi-1.6 for cygwin with dynamic libs
>
>
I think I found the answer to my question on Jeff Squyres blog:
http://blogs.cisco.com/performance/shared-memory-as-an-mpi-transport-part-2/
However now I have a new question, how do I know if my machine uses the
copyin/copyout mechanism or the direct mapping?
Assuming that I am running on
On 05/23/2012 07:30 PM, Patrick Le Dot wrote:
David Singleton writes:
I should have checked earlier - same for MPI_COMPLEX and MPI_COMPLEX8.
David
On 04/27/2012 08:43 AM, David Singleton wrote:
Apologies if this has already been covered somewhere. One of our
David Singleton anu.edu.au> writes:
>
>
> I should have checked earlier - same for MPI_COMPLEX and MPI_COMPLEX8.
>
> David
>
> On 04/27/2012 08:43 AM, David Singleton wrote:
> >
> > Apologies if this has already been covered somewhere. One of our users
> > has noticed that MPI_COMPLEX16 is
I am trying to build openmpi-1.6 for cygwin with dynamic libs
-
./autogen.sh
cd build_dir
source_dir/configure \
LDFLAGS="-Wl,--export-all-symbols -no-undefined" \
--disable-mca-dso \
--without-udapl \
--enable-cxx-exceptions \
On 05/22/2012 10:34 PM, Orion Poplawski wrote:
On 05/21/2012 06:15 PM, Jeff Squyres wrote:
On May 15, 2012, at 10:37 AM, Orion Poplawski wrote:
$ mpicc -showme:link
-pthread -m64 -L/usr/lib64/openmpi/lib -lmpi -ldl -lhwloc
-ldl and -lhwloc should not be listed. The user should only link
On 05/21/2012 06:15 PM, Jeff Squyres wrote:
On May 15, 2012, at 10:37 AM, Orion Poplawski wrote:
$ mpicc -showme:link
-pthread -m64 -L/usr/lib64/openmpi/lib -lmpi -ldl -lhwloc
-ldl and -lhwloc should not be listed. The user should only link against
libraries that they are using directly,
28 matches
Mail list logo