event, but I've no idea what.
Both machines are running OpenMPI 1.4.2 (compiled from same tar file),
installed in /opt/openmpi. The executables are in the same user/path
on each machine (/home/me/src/openmpi/examples), and path,
LD_LIBRARY_PATH, and so on all seem the same.
Any suggestions?
I don't think that could be the problem. I can ssh between machines,
have a coulple of common directories shared with NFS, etc. And OpenMPI
runs (or starts, anyway) under ssh, doesn't it?
James
On Fri, 23 Jul 2010 14:17:48 -0700, Ralph Castain wrote:
Check for a firewall bl
do whatever talking between themselves that's needed by
OpenMPI, while still having a firewall between my system and the outside
world?
Thanks,
James
PS: Hate to kvetch, but wouldn't it save a lot of wasted time if basic
problems like this were addressed in the FAQ?
On Fri, 23 Jul 2010
g on
a corporate/university network where you actually HAVE a sysadmin person
to do these sorts of chores for you, but not much help at all for people
working on their own systems.
James
On Sat, 24 Jul 2010 16:31:12 -0700, Ralph Castain wrote:
On Jul 24, 2010, at 4:40 PM, James wrote:
OK, that's the problem. I turned the firewall off on both machines, and
it works.
Now the question: how do I fix it? I searched through the archives, and
found that it seems to be a p
n: basically, treating each machine as a trusted "network"
of one machine.
It also allows listing of individual machines, e.g. "192.168.10.100
192.168.10.101 192.168.10.102...", but I figured it could get tedious
updating the list on every machine each time I add one.
Thanks,
James
0,000.
Any ideas?
-James
On Wed, Sep 2, 2009 at 12:55 AM, Jeff Squyres wrote:
> Can you try without the --with-threads configure argument?
>
>
> On Aug 28, 2009, at 11:48 PM, James Gao wrote:
>
> Hi everyone, I've been having a pretty odd issue with Slurm and
>> ope
c OSX 10.4.4 (ie, define a range of ports,
TCP and/or UDP). Since this is clearly critical, I suspect that I
must have overlooked some information on the OpenMPI web-site - if
so, please direct me to it. If I haven't, it might be worth a word or
two in the F
s work one
time for each process - the second time MPI_Send is called by process
0, there is a hang.
I am using Mac OSX 10.4.4 and gcc 4.0.1 on both systems, with OpenMPI
1.0.1 installed (compiled from sources). The small tutoria
Jeff,
Thanks for your responses.
On Feb 12, 2006, at 5:23 PM, Jeff Squyres wrote:
On Feb 10, 2006, at 12:18 PM, James Conway wrote:
Open MPI uses random port numbers for all it's communication.
(etc)
Thanks for the explanation. I will live with the open Firewall, and
look at the ipfw
progressing to real
MPI software (which I have kindly been given).
Best regards,
James Conway
--
James Conway, PhD.,
Department of Structural Biology
University of Pittsburgh School of Medicine
Biomedical Science Tower 3, Room 204
openmpi-builder
--James
", MPI::INFO_NULL, port);
printf("Slave found test_service on port, %s\n", port);
intercomm = MPI::COMM_WORLD.Connect(port, MPI::INFO_NULL, 0);
intercomm.Recv(buffer, 3, MPI::INT, 0, PARENT_TAG);
...
>From testing, it looks like it is happening within Connect. What am I doing
incorrectly?
Thank you,
James Barron
I need to configure openmpi 2.0.x so the default does not require the
--allow-run-as-root to be specified with mpirun, i.e. execution of mpirun by
root is allowed by default.
I do not see any option in the configure file to do this.
How do I do this?
Thanks.
Jim Kress
___
openmpi 2.0.x
James,
there is no such a configure option, nor a MCA parameter you can set in
/.../etc/openmpi-mca-params.conf.
since it is strongly advised *not* to run as root, there might be no plans to
have this feature.
though i also strongly suggest you avoid running as root, but if this
close the files or honor the error handler and return an error code
without an abort.
I've tried with with OpenMPI 1.4.3 and 1.5 with the same results.
Attached are the configure, compile and source files and the whole
program follows.
Any help would be appreciated,
Dr. James Overfelt
On Wed, Dec 1, 2010 at 8:28 AM, Rob Latham wrote:
> On Mon, Nov 22, 2010 at 04:40:14PM -0700, James Overfelt wrote:
>> Hello,
>>
>> I have a small test case where a file created with MPI_File_open
>> is still open at the time MPI_Finalize is called. In the actual
&
Accumulate Test
*
* Author: James Dinan
* Date : December, 2010
*
* This code performs N accumulates into a 2d patch of a shared array. The
* array has dimensions [X, Y] and the subarray has dimensions [SUB_X, SUB_Y]
* and begins at index [0, 0]. The input and output buffers are specifie
Strided Accumulate Test:
[f3:1747] *** An error occurred in MPI_Accumlate
[f3:1747] *** on win 3
[f3:1747] *** MPI_ERR_TYPE: invalid datatype
[f3:1747] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)
Thanks,
~Jim.
On 12/14/2010 09:05 AM, Rolf vandeVaart wrote:
Hi James:
I can reproduce the
On 12/16/2010 08:34 AM, Jeff Squyres wrote:
> Additionally, since MPI-3 is updating the semantics of the one-sided
> stuff, it might be worth waiting for all those clarifications before
> venturing into the MPI one-sided realm. One-sided semantics are much
> more subtle and complex than two-sided
Hi Toon,
Can you use non-blocking send/recv? It sounds like this will give you
the completion semantics you want.
Best,
~Jim.
On 2/24/11 6:07 AM, Toon Knapen wrote:
In that case, I have a small question concerning design:
Suppose task-based parallellism where one node (master) distributes
MPLETE(win) initiate a
nonblocking send with tag tag1 to each process in the group of the preceding start call.
No need to wait for the completion of these sends."
The wording 'nonblocking send' startles me somehow !?
toon
On Thu, Feb 24, 2011 at 2:05 PM, James Dinan wrote:
Sudheer,
Locks in MPI don't mean mutexes, they mark the beginning and end of a
passive mode communication epoch. All MPI operations within an epoch
logically occur concurrently and must be non-conflicting. So, what
you're written below is incorrect: the get is not guaranteed to complete
unt
Sure, this is possible and generally works, although it is not defined
by the MPI standard. Regular shared memory rules apply: you may have to
add additional memory consistency and/or synchronization calls depending
on your platform to ensure that MPI sees intended data updates.
Best,
~Jim.
On
Hi all,
I noticed about 18 months ago in the user archives that the question of
heterogeneous support for clusters of Windows / Linux machines was raised,
and at that time this functionality was not supported.
Is this still the case? Are there any near term plans in this direction?
Also . st
Hi all,
I am trying to setup Open-MPI across two Windows 7 machines with UAC
disabled ..
Cygwin with OpenSSH is installed, and I can successfully ssh to each machine
without entry of username and password:
JimT@JimT-PC ~
$ ssh NanoOneQuad
Last login: Tue Feb 7 01:42:02 2012 from jimt-pc
: George Bosilca [mailto:bosi...@eecs.utk.edu]
Sent: Tuesday, February 07, 2012 2:10 PM
To: james.toross...@essetek.com; Open MPI Users
Subject: Re: [OMPI users] O-MPI Support for Windows 7
James,
There is no mention about username or password in OMPI. I guess one of the
applications used in the
eed to run ssh-agent to cache login credentials.
On Feb 6, 2012, at 5:05 PM, James Torossian wrote:
Hi all,
I am trying to setup Open-MPI across two Windows 7 machines with UAC
disabled ..
Cygwin with OpenSSH is installed, and I can successfully ssh to each machine
without entry of us
20 PM
To: Open MPI Users; james.toross...@essetek.com
Cc: Ralph Castain
Subject: Re: [OMPI users] O-MPI Support for Windows 7
Hi James,
One other possibility could be that ssh is actually not used at all. Did you
build Open MPI under Cygwin? Is the ssh module shown up in the ompi_info
output?
The
; james.toross...@essetek.com
Subject: Re: [OMPI users] O-MPI Support for Windows 7
I'm afraid "--mca plm rsh" is not going to work. James is using a Windows
build, which doesn't have the rsh plm module.
There are only two plm modules for windows:
MCA plm: process (MCA ...
MCA plm: c
The patch for limiting the port range used by OpenMPI sounds useful.
This *is* an issue with firewalls. For a dedicated cluster behind a
firewall that's ok, but for harnessing available hardware (eg, Mac
OSX systems) in the wee hours its not. Gets my vote!
James Conway
On Aug 31, 200
t is intended or not.
This particular error can be avoided by excluding xgrid:
./configure CC=icc CXX=icpc F77=ifort F90=ifort --without-xgrid
James Conway
PS. Please note that the instructions for collecting install and make
information are not quite right, maybe out-of-date. On this page
ded the output of "ibv_devinfo",
"ifconfig", and "ulimit -l" in the infiniband_info.txt file. The results of
"ompi_info -all is in the ompi_info.txt file.
I've been tearing my hear out over this, any help would be greatly appreciated.
James Rudd
JLC-Biomedical/
965] Signal code: Address not mapped (1)
[titus:21965] Failing at address: 0x837a004
[titus:21965] [ 0] /lib/i686/libpthread.so.0 [0x40035f93]
[titus:21965] [ 1] python [0x42029180]
[titus:21965] [ 2] /users/james/lib/libopen-pal.so.0(free+0xbc) [0x40e112fc]
[titus:21965] [ 3]
/users/j
Hi,
OK, to answer my own question, I recompiled OpenMPI appending
'--with-memory-manager=none' to configure and now things seem to run
fine. I'm not sure how this might affect performance, but at least
it's working now. Maybe this can be put in the FAQ?
James
On Wed, Jul
Hi,
I'm just using TCP so this isn't a problem for me. Any ideas what
could be causing this segfault?
James
Hi everyone, I've been having a pretty odd issue with Slurm and
openmpi the last few days. I just set up a heterogeneous cluster with
Slurm consisting of P4 32 bit machines and a few new i7 64 bit
machines, all running the latest version of Ubuntu linux. I compiled
the latest OpenMPI 1.3.3 with the
Hi -
configure failed the VALGRIND_CHECK_MEM_IS_ADDRESSABLE test, for
openmpi-1.3.3 or -1.4 with Valgrind 3.5.0 -
I ran configure with
! /bin/csh
#! run configure
#
../configure --prefix=/home/pshare/lib/lf95/openmpi-Vg-1.3.3 \
FC=`which lf95` F77=`which lf95`
y the
installation directory, not the source directory?
On Feb 2, 2010, at 6:23 AM, Conboy, James wrote:
> Hi -
> configure failed the VALGRIND_CHECK_MEM_IS_ADDRESSABLE test,
> for openmpi-1.3.3 or -1.4 with Valgrind 3.5.0 -
>
( For information only )
I reported a bug which stops Totalview saving .mdbg files using tvscript
-
mpirun -V mpirun (Open MPI) 1.4
totalview -vLinux x86 TotalView 8.8.0-0
This is logged ( by Totalview )as
CR 12192 - Tvscript fails to save mdbg file when specified with line
n
Hi -
Have you checked your compiler switches ?? Some have options to
perform IEEE arithmetic, which is supposed to give identical results -
eg
pgf95
-Kieee -Knoieee (default)
Perform floating-point operations in strict conformance with the
IEEE 754 standard. Some optimizations are
be able to work around this by forcing the use of shared Intel
libraries:
$ mpif90 test.f90 -openmp -shared-intel
$ ./a.out
hello
$ mpirun -np 4 ./a.out
hello
hello
hello
hello
Is there a way to resolve this in the OpenMPI build itself instead?
Thanks,
--James
--
James Spencer
http
Hi Thomas,
On Fri, Aug 07, 2015 at 06:39:10PM +0200, Thomas Jahns wrote:
> Hello,
>
> On Aug 7, 2015, at 14:36 , James Spencer wrote:
> >The Intel forum thread alleges that this is (at least for MVAPICH2)
> >because incorrect Intel runtime sources are included in an MPI
Hi,
I am using openmpi with Platform LSF on our cluster that has 10Gbe
connectivity.
Sometimes things work fine but we get a lot of occurences of mpi jobs
not getting off the ground and the following appears in the log...
"ORTE has lost communication with its daemon located on node:
hostna
On 01/10/2015 10:24, Emyr James wrote:
"ORTE has lost communication with its daemon located on node:
hostname: node123
This is usually due to either a failure of the TCP network
connection to the node, or possibly an internal failure of
the daemon itself. We cannot recover from
running Scientific Linux release 7.2.
Regards,
Emyr James
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users
I'm trying to compile MPI with pgf90. I use the following configure
settings:
./configure --prefix=/usr/local/mpi F90=pgf90 F77=pgf77
However, the compiler is set to gfortran:
*** Fortran 90/95 compiler
checking for gfortran... gfortran
checking whether we are using the GNU Fortran compiler...
Thanks! The build went went well with FC=pgf90.
Michael Kluskens wrote:
On Jul 31, 2006, at 1:12 PM, James McManus wrote:
I'm trying to compile MPI with pgf90. I use the following configure
settings:
./configure --prefix=/usr/local/mpi F90=pgf90 F77=pgf77
Besides the other
I just need to confirm that openmpi 1.4.2 doesn't support nested
invocations of mpirun. I found a previous mailing list message the that
effect, but it referred to 1.3.3. I really need this functionality, so
I wanted to make sure openmpi doesn't have it before I start doing
desperate things.
Thanks a lot!
Best,
Pei
Did you ensure that all of the applications were built using the OpenMPI
compilers? Sometimes you *have* to define the CC, CXX, etc when building.
--
James A. Peltier
Technical Director, RHCE
SCIRF | GrUVi @ Simon Fraser University - Burnaby Campus
Phone : 778-78
/mailman/listinfo.cgi/users
The best way I have found to ensure maximum compatibility is to compile a
version of GCC that is not tied to any OS, but that is tied to an
architecture. I then compile all my applications using that compiler and
it has always worked for me.
--
James A. Peltier
Systems
I have an OpenMPI program compiled with a version of OpenMPI built using the
ifort 10.1
compiler. I can compile and run this code with no problem, using the 32 bit
version of ifort. And I can also submit batch jobs using torque with this
32-bit code.
However, compiling the same code to produce a
] Open MPI:Problem with 64-bit openMPI and intel
compiler
What OMPI version are you using?
On Jul 23, 2009, at 3:00 PM, Sims, James S. Dr. wrote:
> I have an OpenMPI program compiled with a version of OpenMPI built
> using the ifort 10.1
> compiler. I can compile and run this cod
thanks to all the responses. I've checked and I am using the proper 64-bit libs
on all nodes. I'll
try upgrading to 1.3.3
Jim
From: users-boun...@open-mpi.org [users-boun...@open-mpi.org] On Behalf Of
Ralph Castain [r...@open-mpi.org]
Sent: Friday, July
Back to this problem.
The last suggestion was to upgrade to 1.3.3, which has been done. Still cannot
get this code to
run in 64 bit mode with torque. What I can do is run the job in l6 bit mode
using a hostfile.
Specifically, if I use
qsub -I -l nodes=2:ppn=1 torque allocates two nodes to the
p your local
lib-path and forward it for you regardless of the launch environment.
On Aug 11, 2009, at 10:17 PM, Sims, James S. Dr. wrote:
> Back to this problem.
>
> The last suggestion was to upgrade to 1.3.3, which has been done.
> Still cannot get this code to
> run in 64 bit mode w
, 2009 at 12:37 PM, Sims, James S. Dr. wrote:
> I have a working 32 bit MPI code which works with either lam or openmpi.
> However
> I have not been able to run this code in 64 bit mode. In attempting to
> isolate the
> problem, I have replaced the MPI code with stubs so I can run
Hi Christian,
I would suggest using mvapich2 instead. It is supposedly faster than OpenMpi on
infiniband and it seems to have fewer options under the hood which means less
things you have to tweak to get it working for you.
Regards,
Emyr James
Head of Scientific IT
CRG -Centre for Genomic
I've been trying to create a derived datatype for use in one-sided
communication, and I find that attempting to modify the extents to account for
potential alignment issues is making things *worse*, at least when one-sided
communication is used. Modifying extents seems to work fine when using th
In case the last message came out garbled because newlines were removed, I've
send it again. Anyway,I've been trying to create a derived datatype for use in
one-sided communication, and I find that attempting to modify the extents to
account for potential alignment issues is making things *worse
60 matches
Mail list logo
