Hi All -
I am working on a networked cache for an out-of-core application, and
currently I have it set up where I have several worker threads, and
one "request" thread per node. The worker threads check the cache on
their own node first, and if there's a miss, they make a request to
the other nod
Greetings,
when MPI_Spawn cannot launch an application for whatever reason, the
entire job is cancelled with some message like the following.
Is there a way to handle this nicely, e.g. by throwing an exception? I
understand, this does not work, when the job is first started with
mpirun, as there is
Ah! It WAS the torque startup script they provide!
It pays to get into the weeds.
Brian Andrus perotsystems
Site Manager | Sr. Computer Scientist
Naval Research Lab
7 Grace Hopper Ave, Monterey, CA 93943
Phone (831) 656-4839 | Fax (831) 656-4866
-Original Message-
From: users-boun
I have checked those out.
I am trying to test limits. If I ssh directly to a node and check,
everything is ok:
[andrus@login1 ~]$ ssh n01 ulimit -l
unlimited
The settings in /etc/security/limits.conf are right too.
Brian Andrus perotsystems
Site Manager | Sr. Computer Scientist
Naval Researc
Check out:
http://www.open-mpi.org/faq/?category=openfabrics#ib-locked-pages
http://www.open-mpi.org/faq/?category=openfabrics#ib-locked-pages-more
In particular, see the stuff about using resource managers.
On Nov 7, 2007, at 7:22 PM, Andrus, Mr. Brian (Contractor) wrote:
Ok, I am having s
Ok, I am having some difficulty troubleshooting this.
If I run my hello program without torque, it works fine:
[root@login1 root]# mpirun --mca btl openib,self -host
n01,n02,n03,n04,n05 /data/root/hello
Hello from process 0 of 5 on node n01
Hello from process 1 of 5 on node n02
Hello from process
Please understand that I'm decent at the engineering side of it. As a
system administrator, I'm a decent engineer.
On the previous configurations, this program seems to run with any
number of processors. I believe these successful users have been using
LAM/MPI. While I was waiting for a reply,
On Wed, Nov 07, 2007 at 07:00:31 -0800, Francesco Pietra wrote:
>
I was lucky, given my modest skill with systems. In a couple of hours the
system is OK again.
DOCK, configured for MPICH and compiled gcc, is now running parallel with
pointing to OpenMPI 1.2.3 compiled ifort/icc. Top -i shows all p
On Wed, Nov 07, 2007 at 07:00:31 -0800, Francesco Pietra wrote:
>
> , according to benchmatcs carried out by a number of guys) (intels are free as
> gnu for my private use). And pointing MPICH for a program compiled gnu C (like
> DOCK) to OpenMPI compiled intel was OK. ifort does not work if no
--- Adrian Knoth wrote:
> On Wed, Nov 07, 2007 at 08:09:14AM -0500, Jeff Squyres wrote:
>
> > I'm not familiar with DOCK or Debian, but you will definitely have
>
> And last but not least,
Surely not last. My OpenMPI was intel compiled. Simple reason: Amber9, as a
Fortran program, runs fast
works fine now.
In earth sciences - at least oceanography and meteorology - Fortran is
still the language of choice.
kb
On Wed, Nov 07, 2007 at 12:25:06 +0100, Adrian Knoth wrote:
> On Wed, Nov 07, 2007 at 10:41:55AM +, Karsten Bolding wrote:
>
> > Hello
>
> Hi!
>
> > there is no support
As Jeff indicated, the degree of capability has improved over time - I'm not
sure which version this represents.
The type of failure also plays a major role in our ability to respond. If a
process actually segfaults or dies, we usually pick that up pretty well and
abort the rest of the job (certai
Support for failure scenarios is something that is getting better over
time in Open MPI.
It looks like the version you are using either didn't properly catch
that there was a failure and/or then cleanly exit all MPI processes.
On Nov 6, 2007, at 9:01 PM, Teng Lin wrote:
Hi,
Just realiz
On Nov 5, 2007, at 4:12 PM, Benjamin, Ted G. wrote:
I have a code that runs with both Portland and Intel compilers
on X86, AMD64 and Intel EM64T running various flavors of Linux on
clusters. I am trying to port it to a 2-CPU Itanium2 (ia64) running
Red Hat Enterprise Linux 4.0; it has
Hi Jeff:
I understand that my question was posed in extremely vague terms. Though,
pointing MPICH to the installation of OpenMPI was suggested by the author of
DOCK and it performed perfectly for a long while, until yesterday. Perhaps,
could you please instruct me how to verify beyond doubt if the
On Wed, Nov 07, 2007 at 08:09:14AM -0500, Jeff Squyres wrote:
> I'm not familiar with DOCK or Debian, but you will definitely have
And last but not least, I'd like to point to the official Debian package
for OMPI:
http://packages.debian.org/openmpi
--
Cluster and Metacomputing Working Gr
I'm not familiar with DOCK or Debian, but you will definitely have
problems if you mix-n-match MPI implementations. Specifically, the
mpi.h files are not compatible between MPICH and Open MPI.
Additionally, you may run into problems if you compile your app with
one version of Open MPI and
I wonder whether any suggestion can be offered about segmentation fault
occurring on running a docking program (DOCK 6.1, written in C) on Debian Linux
amd64 etch, i.e. dual opterons machine. Running DOCK6.1 parallel was OK until
yesterday. I vaguely remember that before these problems I carried ou
On Wed, Nov 07, 2007 at 10:41:55AM +, Karsten Bolding wrote:
> Hello
Hi!
> there is no support for Fortran - even though F77 and F90 are set as
Fortran? Who needs Fortran? ;)
Check line 151 in the Makefile. We've disabled Fortran for our developer
builds, as we're interested in OMPI, not i
Hello
On Wed, Nov 07, 2007 at 11:03:56AM +0100, Adrian Knoth wrote:
> On Wed, Nov 07, 2007 at 09:45:24AM +, Karsten Bolding wrote:
>
> Place the attached Makefile as i.e. /tmp/my-ompi/Makefile, get the svn
> snapshot into /tmp/my-ompi/ompi and just run "make" in /tmp/my-ompi/.
>
> Over her
On Wed, Nov 07, 2007 at 09:45:24AM +, Karsten Bolding wrote:
> Hello
Hi!
> Are there any known issues with ubuntus version of libtool. When I run
Libtool is always an issue ;) To circumvent this, we have a Makefile
fetching the right versions, compiling the whole autotools chain,
prepends t
Hello
As it seems I need a feature only present in the svn-version of OpenMPI
I'm in the process of installing and compiling this version.
I've tried on two different machines.
1) debian everything worked OK.
autoconf 2.61-4
automake 1:1.10+nogfdl-1
libtool 1.5.24-1
ifort Version 10.0
2) ubu
Yes, this feature is currently in the SVN.
You can use the syntax in:
https://svn.open-mpi.org/trac/ompi/ticket/1023
Currently the process affinity doesn't work but the ranks are running
on the machines as specify in the hostfile.
Currently Ralph is working on removing the new syntax from the host
On 06.11.2007, at 10:42, Åke Sandgren wrote:
Hi,
On Tue, 2007-11-06 at 10:28 +0100, Michael Schulz wrote:
Hi,
I've the same problem described by some other users, that I can't
compile anything if I'm using the open-mpi compiled with the Intel-
Compiler.
ompi_info --all
Segmentation fault
On Tue, Nov 06, 2007 at 09:22:50 -0500, Jeff Squyres wrote:
> Unfortunately, not yet. I believe that this kind of functionality is
> slated for the v1.3 series -- is that right Ralph/Voltaire?
thats a pity since performance of the setup is horrible if I can't
control the order.
the svn code w
On Tue, 2007-11-06 at 20:49 -0500, Jeff Squyres wrote:
> On Nov 6, 2007, at 4:42 AM, Åke Sandgren wrote:
>
> > I had the same problem with pathscale.
>
> There is a known outstanding problem with the pathscale problem. I am
> still waiting for a solution from their engineers (we don't know yet
On Tue, Nov 06, 2007 at 09:22:50PM -0500, Jeff Squyres wrote:
> Unfortunately, not yet. I believe that this kind of functionality is
> slated for the v1.3 series -- is that right Ralph/Voltaire?
>
Yes, the file format will be different, but arbitrary mapping will be
possible.
>
> On Nov 5, 20
27 matches
Mail list logo
