You may want to see if you have MacPorts installed. Typically (but not
always), /opt/local is from a MacPorts installation. If it is then it's
very easy to remove mpich and install openmpi.
To check for MacPorts, see if /opt/local/bin/port exists. Then,
sudo port uninstall --follow-dependencies m
rograms via terminal, but if I try to run them in
> Xcode I get an error because it cannot find MPI.h; even if i do a
>
> #import
>
> I suspect that it should work but I am probably missing somethinghow
> are you able to use MPI on Xcode? Gotta change some build settings?
&g
I having some difficulties with building/running 1.6.3 on Mountain Lion
(10.8.2). I build with no errors and install into a prefix directory. I get
the following errors:
...
[bolstadm-lm3:38486] mca: base: component_find: unable to open
/Users/bolstadm/papillon/build/macosx-x86_64/Release/openmpi-1
think of why that would happen offhand. I build
> and run all the time on ML with no problems. Can you deleted that plugin
> and run ok?
>
> Sent from my phone. No type good.
>
> On Feb 10, 2013, at 10:22 PM, "Mark Bolstad"
> wrote:
>
> > I having some difficul
do the shared objects get created in the build cycle?
Mark
On Mon, Feb 11, 2013 at 1:35 PM, Jeff Squyres (jsquyres) wrote:
> Ah -- your plugins are all .a files.
>
> How did you configure/build Open MPI?
>
>
> On Feb 11, 2013, at 11:09 AM, Mark Bolstad
> wrote:
>
> > I
I packed the compile info as requested but the message is to big. Changing
the compression didn't help. I can split it, or do you just want to approve
it out of the hold queue?
Mark
On Mon, Feb 11, 2013 at 3:03 PM, Jeff Squyres (jsquyres) wrote:
> On Feb 11, 2013, at 2:46 PM, Mark
Do you want me to pull a 1.6.3 out of subversion and try
it?
Mark
>
>
> On Feb 11, 2013, at 10:03 PM, Mark Bolstad
> wrote:
>
> > I packed the compile info as requested but the message is to big.
> Changing the compression didn't help. I can split it, or do you just
rsion of libtool that we're using in the OMPI
> 1.6 series still checks for C, C++, and Fortran, even if the project
> doesn't use C++ or Fortran (this has been fixed in later versions of
> libtool).
>
> Can you either uninstall your borked gfortran, install a proper/wo
Just a quick interjection, I also have a dual-quad Nehalem system, HT on,
24GB ram, hand compiled 1.3.4 with options: --enable-mpi-threads
--enable-mpi-f77=no --with-openib=no
With v1.3.4 I see roughly the same behavior, hello, ring work, connectivity
fails randomly with np >= 8. Turning on -v inc
Some additional data:
Without threads it still hangs, similar behavior as before.
All of the tests were run on a system running FC11 with X5550 processors.
I just reran on a node of a RHEL 5.3 cluster with E5530 processors (dual
Nehalam):
- openmpi 1.3.4 and gcc 4.1.2
- No issues: connecti
I have a small test code that I've managed to duplicate the results from a
larger code. In essence, using the sm btl with ISend, I wind up with the
communication being completely serialized, i.e., all the calls from process
1 complete, then all from 2, ...
This is version 1.3.2, vanilla compile. I
ion loop*/
usleep( (unsigned long)(50 * drand48()) );
}
/* Clean up */
for (i = 0; i < BUFFERS; i++)
{
if ( sent[ i ] )
{
sent[ i ] = 0;
MPI_Wait( request[ i ], &status );
}
free( request[ i ] );
free( buffer[ i
Thanks, but that won't help. In the real application the messages are at
least 25,000 bytes long, mostly much larger.
Thanks,
Mark
On Fri, Jun 19, 2009 at 1:17 PM, Eugene Loh wrote:
> Mark Bolstad wrote:
>
> I have a small test code that I've managed to duplicate the resul
Thanks, that at least explains what is going on. Because I have an
unbalanced work load (at least for now) I assume that I'll need to poll. If
I replace the compositor loop with the following, it appears that I prevent
the serialization/starvation and service the servers equally. I can think of
edg
14 matches
Mail list logo
