On Jun 22, 2005, at 4:29 PM, Brian Barrett wrote:
> On Jun 22, 2005, at 3:54 PM, smiler21_at_[hidden] wrote:
>
>> Hi, I'm trying to run a code between Mac and Linux and I'm getting
>> this error:
>>
>> ----------------------------------------------------------------------
>> -------
>> It seems that [at least] one of the processes that was started with
>> mpirun chose a different RPI than its peers. For example, at least
>> the following two processes mismatched in their RPI selections:
>>
>> MPI_COMM_WORLD rank 1: usysv (v7.1.0)
>> MPI_COMM_WORLD rank 0: tcp (v7.0.0)
>>
>> All MPI processes must choose the same RPI module and version when
>> they start. Check your SSI settings and/or the local environment
>> variables on each node.
>> ----------------------------------------------------------------------
>> -------
>>
>> (The mac is node 0.) I read the post on forcing both machines to use
>> tcp, but is there a way to force versions to be the same? Or am I
>> going to have to download the correct versions?
>
> This probably happened because one node has usysv support and the
> other doesn't. You can run "laminfo" on both machines to get a list
> of supported modules. If usysv doesn't appear on the Mac list, then
> you'll either have to use a module that is available on both machines
> or rebuild LAM for the Mac.
>
> Note that there is a bug in the USYSV rpi for G5 hardware. If you are
> running on a G5, you should either avoid the USYSV rpi or upgrade to
> LAM 7.1.2b22.
I almost forgot. On the Macs, there is a limited amount of SYSV shared
memory available by default. If you are using another application that
uses SYSV shared memory (Mysql and Apache both do, I believe), you can
easily bump up against system limits. Also, if LAM jobs crash, SYSV
shared memory can be leaked until either lamclean or lamhalt are run
(to clean up resources or shut down the LAM universe). That could be
one reason that your Mac decided not to use the USYSV rpi. Try
shutting down any servers like Apache and MySQL that you might have
running, and lamclean, and see if that helps at all.
Brian
--
Brian Barrett
LAM/MPI developer and all around nice guy
Have a LAM/MPI day: http://www.lam-mpi.org/
|
