Hi all,
Does anyone know if it's possible to get the orte jobid from the mpirun
command? If not, how are you supposed to get it to use with orte-ps? Also,
orte-ps reports the jobid in [x,y] notation, but the jobid argument seems to be
an integer. How does that work?
Thanks,
Greg
on to print the jobid, and
> that utility always shows the jobid in component form. Again, could add or
> just use the integer version.
>
>
> On Jul 22, 2011, at 7:01 AM, Greg Watson wrote:
>
>> Hi all,
>>
>> Does anyone know if it's possible to get the orte jobid fr
t; this option that isn't working properly - orte-ps returns info from all
>> mpiruns and doesn't check to provide only data from the given pid.
>>
>> I'll fix that part, and implement the parsable output.
>>
>>
>> On Jul 22, 2011, at 8:55 PM, Ralph Castai
That would probably be more intuitive.
Thanks,
Greg
On Jul 25, 2011, at 2:28 PM, Ralph Castain wrote:
> job 0 is mpirun and its daemons - I can have it ignore that job as I doubt
> users care :-)
>
> On Jul 25, 2011, at 12:25 PM, Greg Watson wrote:
>
>> Ralph,
>>
Ralph,
Looking good so far. I did notice that ompi-ps always seems to have an exit
code of 243. Is that on purpose?
Greg
On Jul 25, 2011, at 4:44 PM, Ralph Castain wrote:
> r24944 - let me know how it works!
>
>
> On Jul 25, 2011, at 1:01 PM, Greg Watson wrote:
>
>>
Can we also have an option to wrap stdout/err in XML tags, or were you
already planning that?
Greg
On Aug 28, 2008, at 8:51 AM, Ralph Castain wrote:
The revised IOF design calls for several new cmd line options:
1. specify which procs are to receive stdin. The options that were
to be
Hi,
Has there been a change in the behavior of the -display-map option has
changed recently in the 1.3 branch. We're now seeing the host name as
a fully resolved DN rather than the entry that was specified in the
hostfile. Is there any particular reason for this? If so, would it be
Ralph,
At the moment -display-map shows the process mapping when mpirun first
starts, but I'm wondering about processes created dynamically. Would
it be possible to trigger a map update when MPI_Spawn is called?
Regards,
Greg
whenever MPI_Spawn is called.
We didn't provide a mechanism by which you could only display-map
for MPI_Spawn (and not for the original mpirun), but it would be
trivial to do so - just have to define an info-key for that purpose.
Is that what you need?
On Sep 11, 2008, at 5:35 AM, Greg
e or -host (or in an
allocation from a resource manager) by non-FQDN, we just assume they
know what they are doing and the name will correctly resolve to a
unique address.
On Sep 10, 2008, at 9:45 AM, Greg Watson wrote:
Hi,
Has there been a change in the behavior of the -display-map option
has change
Hi all,
Has a release date been set for 1.3?
Thanks,
Greg
ould
readily solve the problem.
Ralph
On Sep 19, 2008, at 7:18 AM, Greg Watson wrote:
Ralph,
The problem we're seeing is just with the head node. If I specify a
particular IP address for the head node in the hostfile, it gets
changed to the FQDN when displayed in the map. This is a problem
ile plus the name we resolved it to. Of course, --
xml would cause it to be in xml format.
Would that meet your needs?
Ralph
On Oct 15, 2008, at 3:12 PM, Greg Watson wrote:
Hi Ralph,
We've been discussing this back and forth a bit internally and
don't really see an easy solution. Our pro
ot;.
Am I missing something? If so, please do correct me - I would be
happy to provide a tool if that would make it easier. Just not sure
what that tool would do.
Thanks
Ralph
On Oct 19, 2008, at 1:59 PM, Greg Watson wrote:
Ralph,
It seems a little strange to be using mpirun for this, but ba
waiting for:
1. Some FT stuff that Tim/Josh think can be done by this weekend
2. A critical code review for a big openib BTL change that will be
done when Pasha and I are at the Chicago Forum meeting on Monday
On Oct 15, 2008, at 4:48 PM, Greg Watson wrote:
Hi all,
Has a release date
so you can actually get the info as you execute the job, if you
want. The xml tag is "noderesolve" - let me know if you need any
changes.
Ralph
On Oct 22, 2008, at 11:55 AM, Greg Watson wrote:
Ralph,
I guess the issue for us is that we will have to run two commands
to get the
Ralph, will this be in 1.3rc1?
Thanks,
Greg
On Nov 24, 2008, at 3:06 PM, Greg Watson wrote:
Great, thanks. I'll take a look once it comes over to 1.3.
Cheers,
Greg
On Nov 24, 2008, at 2:59 PM, Ralph Castain wrote:
Yo Greg
This is in the trunk as of r20032. I'll bring it over to 1.3
Hi,
In 1.2.x, the rds_hostfile_path parameter pointed to openmpi-default-
hostfile by default. This parameter has been replaced with
orte_default_hostfile in 1.3, but now it defaults to . Was there
any particular reason for the default value to change?
Greg
"/>" not ">".
Thanks,
Greg
On Nov 24, 2008, at 3:06 PM, Greg Watson wrote:
Great, thanks. I'll take a look once it comes over to 1.3.
Cheers,
Greg
On Nov 24, 2008, at 2:59 PM, Ralph Castain wrote:
Yo Greg
This is in the trunk as of r20032. I'll brin
with the old "hostfile" behavior,
but could lead to some confusion in its new usage.
Any preferences/thoughts?
Ralph
On Dec 5, 2008, at 9:15 AM, Greg Watson wrote:
Hi,
In 1.2.x, the rds_hostfile_path parameter pointed to openmpi-
default-hostfile by default. This paramete
be:
or:
Would either of these be possible?
Thanks,
Greg
On Dec 8, 2008, at 2:18 PM, Greg Watson wrote:
Ok thanks. I'll test from trunk in future.
Greg
On Dec 8, 2008, at 2:05 PM, Ralph Castain wrote:
Working its way around the CMR process now.
Might
ome places to
achieve it due to the inherent async nature of the beast.
On Jan 13, 2009, at 12:17 PM, Greg Watson wrote:
Ralph,
The XML is looking better now, but there is still one problem. To
be valid, there needs to be only one root element, but currently
you don't have any (or many).
d-output, so perhaps some testing will help us
debug and validate it adequately for 1.3.1?
Thanks
Ralph
On Jan 14, 2009, at 7:02 AM, Greg Watson wrote:
Ralph,
The only time we use the resolved names is when we get a map, so
we consider them part of the map output.
If quasi-XML i
should try and iterate it so any changes can make 1.3.1
as well.
Thanks!
Ralph
On Jan 15, 2009, at 11:03 AM, Greg Watson wrote:
Ralph,
I think the second form would be ideal and would simplify things
greatly.
Greg
On Jan 15, 2009, at 10:53 AM, Ralph Castain wrote:
Here is what I was able
X-OriginalArrivalTime: 16 Jan 2009 18:08:11.0165 (UTC)
FILETIME=[646AA4D0:01C97805]
Er... whoops. This looks like my mistake (I just recently add
MPI_REDUCE_LOCAL to the trunk -- not v1.3).
I could have sworn that I tested this on a Mac, multiple times.
I'll test again...
On Jan 16,
as of r20284 - I'll file the request to
have it moved to 1.3.1.
Let me know if you get a chance to test the stdout/err stuff in the
trunk - we should try and iterate it so any changes can make 1.3.1
as well.
Thanks!
Ralph
On Jan 15, 2009, at 11:03 AM, Greg Watson wrote:
Ralph,
I think
, I can force tag-output "on" by default whenever -xml is
specified.
Ralph
On Jan 16, 2009, at 12:52 PM, Greg Watson wrote:
Ralph,
Is there something I need to do to enable stdout/err encapsulation
(apart from -xml)? Here's what I see:
$ mpirun -mca orte_show_resolved_nodena
.
If you like, I can force tag-output "on" by default whenever -xml is
specified.
Ralph
On Jan 16, 2009, at 12:52 PM, Greg Watson wrote:
Ralph,
Is there something I need to do to enable stdout/err encapsulation
(apart from -xml)? Here's what I see:
$ m
, at 8:08 AM, Greg Watson wrote:
Ralph,
The encapsulation is not quite right yet. I'm seeing this:
[1,0]n = 0
[1,1]n = 0
but it should be:
n = 0
n = 0
Thanks,
Greg
On Jan 20, 2009, at 9:20 AM, Ralph Castain wrote:
You need to add --tag-output - this is a separate option as it
applies both
Ralf,
I've just noticed that if I use '-xml -display-map', I get the xml
version of the map and then the non-xml version is sent to stderr
(wrapped in xml tags). Was this by design? In my view it would be
better to suppress the non-xml map altogether if the -xml option. 1.4
seems to do
at 7:39 AM, Ralph Castain <r...@open-mpi.org>
wrote:
Hmmm...no, that's a bug. I'll fix it.
Thanks!
On Fri, May 1, 2009 at 7:24 AM, Greg Watson <g.wat...@computer.org>
wrote:
Ralf,
I've just noticed that if I use '-xml -display-map', I get the xml
version of the map and then
, at 10:47 AM, Greg Watson wrote:
Arrgh! Sorry, my bad. I must have been linked against an old version
or something. When I recompiled the output went away.
Greg
On May 1, 2009, at 10:09 AM, Ralph Castain wrote:
Interesting - I'm not seeing this behavior:
graywolf54:trunk rhc$ mpirun -n 3 --xml
Ralph,
In life, nothing is ever easy...
While the XML output is working well, I've come across an issue with
stdout/stderr. Unfortunately it's not just enough to wrap it in tags,
because it's possible that the output will contain XML formatting
information. There are two ways to get
nternal variables,
and would avoid any conflicts unless the user were truly stupid - in
which case, the onus would be on them.
Would that resolve the problem?
Ralph
On Tue, May 26, 2009 at 5:42 AM, Ralph Castain <r...@open-mpi.org>
wrote:
On Mon, May 25, 2009 at 9:10 AM, Greg
revisions to the trunk in r21285 - see what you
think...
Ralph
On Tue, May 26, 2009 at 1:55 PM, Greg Watson <g.wat...@computer.org>
wrote:
Ralph,
Both my proposals are correct XML and should be parsable by any
conforming XML parser. Just changing the tags will not work bec
Ralph,
One of our users is seeing the following output with the XML option
enabled (1.3.3):
time_mix_freq = 17
Time mixing option:
avgfit -- time averaging
with timestep chosen to fit exactly into one day or
coupling interval
Averaging time steps are at step numbers2,17 each
day
, 2009, at 12:16 PM, Greg Watson wrote:
Ralph,
One of our users is seeing the following output with the XML option
enabled (1.3.3):
time_mix_freq = 17
Time mixing option:
avgfit -- time averaging
with timestep chosen to fit exactly into one day
or coupling interval
Averaging time steps
Ralph,
Would it be possible to get mpirun to issue start and end tags if the -
xml option is used? Currently there is no way to determine when the
output starts and finishes, which makes parsing the XML tricky,
particularly if something else generates output (e.g. the shell).
Something
.
It looks like you want the mpirun tags to flow around all output
during the run - i.e., there is only one pair of mpirun tags that
surround anything that might come out of the job. True?
If so, that would be trivial.
On Aug 14, 2009, at 9:25 AM, Greg Watson wrote:
Ralph,
Would it be possible
ry
and let me know if that meets requirements? If so, I'll move it to
1.3.4.
Thanks
Ralph
On Aug 17, 2009, at 6:42 AM, Greg Watson wrote:
Hi Ralph,
Yes, you'd just need issue the start tag prior to any other XML
output, then the end tag when it's guaranteed all XML other output
has been sen
stderr, while the
tag is coming over stdout.
On Tue, Aug 18, 2009 at 12:53 PM, Greg Watson
<g.wat...@computer.org> wrote:
Hi Ralph,
I'm seeing something strange. When I run "mpirun -mca
orte_show_resolved_nodenames 1 -xml -display-map
Ralph,
Looks like it's working now.
Thanks,
Greg
On Aug 18, 2009, at 5:21 PM, Ralph Castain wrote:
Give r21836 a try and see if it still gets out of order.
Ralph
On Aug 18, 2009, at 2:18 PM, Greg Watson wrote:
Ralph,
Not sure that's it because all XML output should be via stdout.
Greg
quot;. This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
------
On Aug 19, 2009, at 10:48 AM, Greg Watson wrote:
Ralph,
Looks like it's working now.
Thanks,
Greg
O
dy to test!
Ralph
On Aug 20, 2009, at 11:16 AM, Greg Watson wrote:
Ralph,
One more thing. Even with XML enabled, I notice that some error
messages are still sent to stderr without XML tags (see below.) Any
chance these could be sent to stdout wrapped in
tags?
Thanks,
Greg
$ m
led to start
Cheers,
Greg
On Aug 20, 2009, at 3:24 PM, Ralph Castain wrote:
Okay - try r21858.
Ralph
On Aug 20, 2009, at 12:36 PM, Greg Watson wrote:
Hi Ralph,
Cool!
Regarding the scope of the tags, I never really thought about
output from the command itself. I propose that any output
rt
Cheers,
Greg
On Aug 20, 2009, at 3:24 PM, Ralph Castain wrote:
Okay - try r21858.
Ralph
On Aug 20, 2009, at 12:36 PM, Greg Watson wrote:
Hi Ralph,
Cool!
Regarding the scope of the tags, I never really thought about
output from the command itself. I propose that any output that
can't oth
Ralph,
Would this be doable? If we could guarantee that the only output that
went to the file was XML then that would solve the problem.
Greg
On Aug 28, 2009, at 5:39 AM, Ashley Pittman wrote:
On Thu, 2009-08-27 at 23:46 -0400, Greg Watson wrote:
I didn't realize it would
this and felt this might represent the
cleanest solution. Sound okay?
On Aug 28, 2009, at 6:33 AM, Greg Watson wrote:
Ralph,
Would this be doable? If we could guarantee that the only output
that went to the file was XML then that would solve the problem.
Greg
On Aug 28, 2009, at 5:39
e arg -xml-
file foo as discussed below.
You can also specify it as an MCA param: -mca orte_xml_file foo, or
OMPI_MCA_orte_xml_file=foo
Let me know how it works
Ralph
On Aug 31, 2009, at 7:26 PM, Greg Watson wrote:
Hey Ralph,
Unfortunately I don't think this is going to work fo
Hi Jeff,
The problem is that I'm not running the command from java (which has
it's own issues), but rather the command is started by the ssh shell/
exec service. Unfortunately ssh only provides stdin, stdout, and
stderr forwarding on fd's 0-2. There is no mechanism to do anything
else. It
The most appealing thing about the XML option is that it just works
"out of the box." Using a library API invariably requires compiling an
agent or distributing pre-compiled binaries with all the associated
complications. We tried that in the dim past and it was pretty
unworkable. The
Rich,
Have you updated your developer tools to Xcode 3.2.1? If you still have the old
developer tools you were using before upgrading to SL, this may be the problem.
Greg
On Jan 24, 2010, at 7:33 PM, Paul H. Hargrove wrote:
> I build ompi-1.3.3 on Snow Leopard with no problems.
> I have not
When I run configure under Snow Leopard (this is OMPI 1.3.4), I get the
following:
checking if C and Fortran 77 are link compatible... no
**
It appears that your Fortran 77 compiler is unable to link against
object files created
On Feb 17, 2010, at 2:01 AM, Ralf Wildenhues wrote:
> Hello Greg,
>
> * Greg Watson wrote on Tue, Feb 16, 2010 at 07:03:30PM CET:
>> When I run configure under Snow Leopard (this is OMPI 1.3.4), I get the
>> following:
>>
>> checking if C a
Ralph,
I notice that you've got support in the XML output code to display the pids of
the processes, but I can't see how to enable them. Can you give me any pointers?
Thanks,
Greg
are initialized.
>
> On Feb 23, 2010, at 12:58 PM, Greg Watson wrote:
>
>> Ralph,
>>
>> I notice that you've got support in the XML output code to display the pids
>> of the processes, but I can't see how to enable them. Can you
attach.
>
> Have it for you in the trunk this weekend. Can you suggest an xml format you
> would like? Otherwise, I'll just use the current proc output (used in the map
> output) and add a "pid" field to it.
>
> On Thu, Feb 25, 2010 at 10:43 AM, Greg Watson <
I just checked out a new version and it seems ok. I don't know what
the problem was.
Thanks,
Greg
On Aug 4, 2005, at 1:07 PM, Jeff Squyres wrote:
Greg --
Did this get resolved? Sorry -- this slipped by me in inbox...
On Aug 1, 2005, at 5:56 PM, Greg Watson wrote:
Further this email
in the request
progress is not occurring correctly.
Thanks!
On Sep 18, 2005, at 5:59 PM, Greg Watson wrote:
Jeff,
Yes, count is 2, but completed returns 1 on the first call and
-32766
on the second call. Sounds like this may be a bug?
Greg
On Sep 17, 2005, at 8:11 AM, Jeff Squyres wrote
Hi,
Trying to install ompi on a bproc machine with no network filesystem.
I've copied the contents of the ompi lib directory into /tmp/ompi on
each node and set my LD_LIBRARY_PATH to /tmp/ompi. However when I run
the program, I get the following error. Any suggestions on what else
I need
You probably already know this, but this problem is still present in
the trunk. It appears to be fixed in the 1.0.x tree.
Greg
to the v1.0 branch (not the other way around).
What kind of systems are you running into this on?
On Nov 30, 2005, at 10:37 AM, Greg Watson wrote:
You probably already know this, but this problem is still present in
the trunk. It appears to be fixed in the 1.0.x tree.
Greg
ting
So it looks like you're doing something that breaks with normal
optimization (I presume -O3) but works otherwise.
FC4 is using gcc 4.0.0 20050519.
Suggestions on how to proceed would be appreciated.
Greg
On Dec 1, 2005, at 9:19 AM, Jeff Squyres wrote:
On Dec 1, 2005, at 10:58 A
on't know, whether it's segfaulting at that particular line, but
could You
please print the argv, since I guess, that might be the
local_exec_index
into the argv being wrong?
Thanks,
Rainer
On Saturday 17 December 2005 19:16, Greg Watson wrote:
Here's the stacktrace:
#0 0x00ae1fe8 in orte_
,
not
the cause (seems likely, because mca_rsh_pls_component is a
statically-defined variable -- accessing a member on it should
definitely not cause a segv). :-(
On Dec 18, 2005, at 12:11 PM, Greg Watson wrote:
Sure seems like it:
(gdb) p *mca_pls_rsh_component.argv@4
$12 = {0x90e0428 &quo
I'm building OMPI 1.0.2a9 on a bproc machine (Yellow Dog Linux 4.0/
ppc). It just has an ethernet interface, no fancy network.
I've tried configuring as follows:
./configure --enable-static --disable-shared --without-threads --with-
devel-headers
and
./configure --enable-static
is definitely linking in the pthread library.
Cheers,
Greg
On Mar 17, 2006, at 8:35 AM, Ralf Wildenhues wrote:
Hi Greg,
* Greg Watson wrote on Fri, Mar 17, 2006 at 04:17:27PM CET:
./configure --enable-static --disable-shared --without-threads --
with-
devel-headers
./configure --enable-static
Hi all,
We've just run across a rather tricky issue. We're calling
opal_event_loop() to dispatch orte events to an orted that has been
launched separately. However if the orted dies for some reason (gets
a signal or whatever) then opal_event_loop() is calling exit().
Needless to say,
we can
discuss it.
Ralph
Greg Watson wrote:
The simplest thing for us would be for opal_event_loop() to return
an error value. That way we can detect the situation and clean up
our system. At the moment we're not trying to restart orted, so
clean recovery of orte is not that important
On the web site download pages, I see various builds for 1.0.x, 1.1.x
and nightly builds for 1.3.x. Would you please also put builds up for
the 1.2 branch so that we have something to build/test against?
Thanks,
Greg
This a new feature of OMPI? The ability to perform requests before
they are asked for... spooky!
Greg
On Nov 2, 2006, at 10:34 AM, Jeff Squyres wrote:
I actually up the v1.2 nightly page last night:
http://www.open-mpi.org/nightly/
On Nov 2, 2006, at 12:28 PM, Greg Watson wrote
It would be of great help for the Eclipse Parallel Tools Platform if
this was working. We get lots of requests for PTP on Windows, but
lack of OMPI support has prevented this to date.
Regards,
Greg
On Nov 18, 2006, at 12:39 PM, George Bosilca wrote:
I'm impressed that it work with cygwin
(Tried to open a bug, but I don't seem to have access...)
Environment:
Fedora Core 5 (actually I think any Linux will do)
OMPI 1.2b1 (./configure --with-devel-headers)
Symptom:
MPI_Init(, ) corrupts the argc variable.
Repeat By:
1. Compile the following program using 'mpicc -g -o mpitest
On Jan 19, 2007, at 2:17 PM, Li-Ta Lo wrote:
On Fri, 2007-01-19 at 13:25 -0700, Greg Watson wrote:
Bluesteel is a 64bit bproc machine. I configured with:
./configure --with-devel-headers --disable-shared --enable-static
When I attempt to run an MPI program:
[bluesteel.lanl.gov:28663
On Jan 22, 2007, at 9:48 AM, Ralph H Castain wrote:
On 1/22/07 9:39 AM, "Greg Watson" <gwat...@lanl.gov> wrote:
I tried adding '-mca btl ^sm -mca mpi_preconnect_all 1' to the mpirun
command line but it still fails with identical error messages.
I don't unde
On Jan 22, 2007, at 9:48 AM, Ralph H Castain wrote:
On 1/22/07 9:39 AM, "Greg Watson" <gwat...@lanl.gov> wrote:
I tried adding '-mca btl ^sm -mca mpi_preconnect_all 1' to the mpirun
command line but it still fails with identical error messages.
I don't unde
I have been using this define to implement the orte_stage_gate_init()
functionality in PTP using OpenMPI 1.2b1 for some months now. As of
1.2b3 it appears that this define has been removed. New users
attempting to build PTP against the latest 1.2b3 build are
complaining that they are
AM, Ralph Castain wrote:
On 1/26/07 11:36 PM, "Greg Watson" <gwat...@lanl.gov> wrote:
I have been using this define to implement the orte_stage_gate_init()
functionality in PTP using OpenMPI 1.2b1 for some months now. As of
1.2b3 it appears that this define has been re
2.0 design allows for it, but we haven't implemented that yet -
probably a few months away.
Hope that helps
Ralph
On 1/29/07 6:45 PM, "Ralph Castain" <r...@lanl.gov> wrote:
On 1/29/07 5:57 PM, "Greg Watson" <gwat...@lanl.gov> wrote:
Ralph,
On Jan 29, 20
On Jan 30, 2007, at 9:39 AM, Ralph H Castain wrote:
On 1/30/07 9:24 AM, "Greg Watson" <gwat...@lanl.gov> wrote:
Yes, we need the hostfile information before job execution. We call
setup_job() before a debug job to request a process allocation for
the application being
On Feb 3, 2007, at 6:51 AM, Ralph Castain wrote:
On 2/2/07 8:44 AM, "Greg Watson" <gwat...@lanl.gov> wrote:
We're launching a seed daemon so that we can get registry persistence
across multiple job launches. However, there is a race condition
between launching the daem
On Feb 3, 2007, at 10:35 AM, Ralph Castain wrote:
Something did occur to me that *might* help with the problem of
detecting
when the seed is running. There is an option to orted "-- report-
uri pipe"
that will cause the orted to write it's uri to the specified pipe.
This
comes after the
DSOs
On Mar 9, 2007, at 7:54 PM, Greg Watson wrote:
What changed between rc1 and rc2?
Greg
On Mar 9, 2007, at 1:50 PM, Tim Mattox wrote:
Hi All,
The second release condidate of v1.2 is now up on the website:
http://www.open-mpi.org/software/ompi/v1.2/
Please run it through it's paces as best
of being
sent across OOB) could be incorrectly removed from the list, later
causing either a segv in production builds or, more reliably, an
assertion failure in debugging builds.
On Mar 9, 2007, at 10:49 PM, Greg Watson wrote:
Thanks. I was seeing an error when I shut down orted. Sounds like
it's
Termination seems to be working again with this version. Don't know
if it was something I was doing or not, but I'm happy now... :-)
Greg
On Mar 12, 2007, at 5:11 PM, Tim Mattox wrote:
Hi All,
The third release candidate of v1.2 is now up on the website:
Looks good.
Greg
On Mar 13, 2007, at 5:37 PM, Tim Mattox wrote:
Hi All,
The fourth release candidate of v1.2 is now up on the website:
http://www.open-mpi.org/software/ompi/v1.2/
Please run it through it's paces as best you can.
This fixes an incorrect result in MPI_Allgather when
using
Is this a known problem? Building ompi 1.2 on RHEL4:
./configure --with-devel-headers --without-threads
(actually tried without '--without-threads' too, but no change)
$ mpirun -np 2 test
[beth:06029] *** Process received signal ***
[beth:06029] Signal: Segmentation fault (11)
[beth:06029]
Oh, and this is a single x86 machine. Just trying to launch locally.
$uname -a
Linux 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006 i686
i686 i386 GNU/Linux
Greg
On Mar 22, 2007, at 12:17 PM, Greg Watson wrote:
Is this a known problem? Building ompi 1.2 on RHEL4:
./configure
problem -- my cluster is RHEL4U4 -- I use it for many
thousands of runs of the OMPI v1.2 branch every day...
Can you see where it's dying in orte_init_stage1?
On Mar 22, 2007, at 2:17 PM, Greg Watson wrote:
Is this a known problem? Building ompi 1.2 on RHEL4:
./configure --with-devel-headers
launcher are you trying to use?
On Mar 22, 2007, at 2:35 PM, Greg Watson wrote:
gdb says this:
#0 0x2e342e33 in ?? ()
#1 0xb7fe1d31 in orte_pls_base_select () from /usr/local/lib/
libopen-
rte.so.0
#2 0xb7fc50cb in orte_init_stage1 () from /usr/local/lib/libopen-
rte.so.0
#3 0xb7fc84be
Hi,
Until now I haven't had to worry about the opal/orte thread model.
However, there are now people who would like to use ompi that has
been configured with --with-threads=posix and --with-enable-mpi-
threads. Can someone give me some pointers as to what I need to do in
order to make
On Aug 27, 2007, at 10:04 PM, Jeff Squyres wrote:
On Aug 27, 2007, at 2:50 PM, Greg Watson wrote:
Until now I haven't had to worry about the opal/orte thread model.
However, there are now people who would like to use ompi that has
been configured with --with-threads=posix and --with-enable
Hi,
Since I upgraded to MacOS X 10.5.1, I've been having problems running
MPI programs (using both 1.2.4 and 1.2.5). The symptoms are
intermittent (i.e. sometimes the application runs fine), and appear as
follows:
1. One or more of the application processes die (I've see both one and
Hi all,
Ralph informs me that significant functionality has been removed from
ORTE in 1.3. Unfortunately this functionality was being used by PTP to
provide support for OMPI, and without it, it seems unlikely that PTP
will be able to work with 1.3. Apparently restoring this lost
e contributed directly.
Sidenote: I was also under the impression that PTP was being re-
geared
towards STCI and moving away from ORTE anyway. Is this incorrect?
On Mar 4, 2008, at 3:24 PM, Greg Watson wrote:
Hi all,
Ralph informs me that significant functionality has been removed
from
ORT
stain" <r...@lanl.gov> wrote:
Hmmm...well, it was working about 3 hours ago! I'll try to take a
look
tonight, but it may be tomorrow.
Try rolling it back just a little to r18513 - that's the last rev I
tested
on my Mac.
On 5/27/08 5:00 PM, "Greg Watson" <g.wat...@com
n" <r...@lanl.gov> wrote:
Hmmm...well, it was working about 3 hours ago! I'll try to take a
look
tonight, but it may be tomorrow.
Try rolling it back just a little to r18513 - that's the last rev I
tested
on my Mac.
On 5/27/08 5:00 PM, "Greg Watson" <g.wat...@computer.
/platform/lanl/macosx-dynamic
In that directory, you will also find platform files for static
builds under
both Tiger and Leopard (slight differences).
ralph
On 5/27/08 8:01 PM, "Greg Watson" <g.wat...@computer.org> wrote:
Ralph,
I tried rolling back to 18513 bu
I'm getting the following when I try and build 1.3 from SVN:
gcc -DHAVE_CONFIG_H -I. -I../../adio/include -DOMPI_BUILDING=1 -I/
Users/greg/Documents/workspaces/ptp_head/ompi/ompi/mca/io/romio/
romio/../../../../.. -I/Users/greg/Documents/workspaces/ptp_head/ompi/
Anton,
I'm using Subversive and it seems to work fine. I wonder if there's
something wrong with your setup?
Greg
On Aug 4, 2008, at 2:01 PM, Anton Soppelsa wrote:
Dear OpenMPI repository maintainers,
I tryed to download the source code of OpenMPI with a couple of SVN
graphical clients,
1 - 100 of 103 matches
Mail list logo
