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:
>
>> T
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,
>>
is
>> 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,
n orte utility function 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 pos
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
s to 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 Watso
haps when debuggers 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 se
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
:-).
Greg
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
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
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 t
t;
functionality in that "most" of OMPI's output is XML-ified, but
there's oodles and oodles of corner cases where output is *not* XML-
ified. The above proposal seems to be the best idea so far on how
to address this issue in a holistic way (rather than adding a bunch
m
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 other
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
s a new cmd line 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
tted about 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, 200
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 be s
n 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 otherwise be
es failed 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
it is ready 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,
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.
Tha
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 std
over stderr, while the
tag is coming over stdout.
On Tue, Aug 18, 2009 at 12:53 PM, Greg Watson
wrote:
Hi Ralph,
I'm seeing something strange. When I run "mpirun -mca
orte_show_resolved_nodenames 1 -xml -display
try
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 o
thers.
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 p
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 lik
, 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,
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
revisions to the trunk in r21285 - see what you
think...
Ralph
On Tue, May 26, 2009 at 1:55 PM, Greg Watson
wrote:
Ralph,
Both my proposals are correct XML and should be parsable by any
conforming XML parser. Just changing the tags will not work because
any text that contains "&&
tion for internal 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
wrote:
On Mon, May 25, 2009 at 9:10 AM, Greg Watson
wrote:
Ralp
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 around
, 2009, 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$ mp
09 at 7:39 AM, Ralph Castain
wrote:
Hmmm...no, that's a bug. I'll fix it.
Thanks!
On Fri, May 1, 2009 at 7:24 AM, Greg Watson
wrote:
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 se
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 th
2009, 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
ap
tions.
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
.
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:
$ mpirun -mca orte_
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
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, 2009, at 12:58 PM, Greg Watson wrote:
When I try to build trunk, it fails with:
i_f77.lax/libmpi_f77_pmpi.a/pwin_unlock_f.o .l
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 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
ml --tagged-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 quas
some 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:
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 n
though, so I don't really care that much. But I
would like to understand why Eclipse cares so we can factor that
into any future thinking.
Ralph
On Dec 12, 2008, at 7:11 AM, Greg Watson wrote:
From our perspective, it would be good if it could default to the
old behavior (in 1.3 if
e default-hostfile best aligns 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-host
miss a release window.
Anyway, hopefully this one will make the 1.3.0 release cutoff.
Thanks
Ralph
On Dec 8, 2008, at 9:56 AM, Greg Watson wrote:
Hi Ralph,
This is now in 1.3rc2, thanks. However there are a couple of
problems. Here is what I see:
[Jarrah.watson.ibm.com:58957] res
"/>" 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
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
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 t
s"
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
. 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 been set for
n --do-not-launch".
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 mpi
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.
to implement in your code and would
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 displ
Hi all,
Has a release date been set for 1.3?
Thanks,
Greg
e nodes in a hostfile 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 -d
y-map 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:3
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
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
possib
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 supp
ality, not performance.
Give that a try and see if it completes. If so, then the problem
probably is related to the ticket cited by Terry. Otherwise, we'll
have to consider other options.
Ralph
On Aug 4, 2008, at 5:50 PM, Greg Watson wrote:
Configuring with ./configure --prefix=/usr/local/op
, I'm having no problem running your code on my Mac w/10.5,
both PowerPC and Intel.
Ralph
On Aug 4, 2008, at 3:10 PM, Greg Watson wrote:
Yes the application does sends/receives. No, it doesn't seem to be
getting past MPI_Init.
I've reinstalled from a completely new 1.3 bran
ould
your issue be related to the following ticket?
https://svn.open-mpi.org/trac/ompi/ticket/1378
--td
Greg Watson wrote:
I'm seeing the same behavior on trunk as 1.3. The program just hangs.
Greg
On Aug 4, 2008, at 2:25 PM, Ralph Castain wrote:
Well, I unfortunately cannot test this
w - at least, it is fixed
on the trunk for me under that same system. I'll check 1.3 now - it
could be that some commits are missing over there.
On Aug 4, 2008, at 12:06 PM, Greg Watson wrote:
I have a fairly simple test program that runs fine under 1.2 on
MacOS X 10.5 . When I recomp
me under that same system. I'll check 1.3 now - it
could be that some commits are missing over there.
On Aug 4, 2008, at 12:06 PM, Greg Watson wrote:
I have a fairly simple test program that runs fine under 1.2 on
MacOS X 10.5 . When I recompile and run it under 1.3 (head of 1.3
bra
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,
I have a fairly simple test program that runs fine under 1.2 on MacOS
X 10.5 . When I recompile and run it under 1.3 (head of 1.3 branch) it
just hangs.
They are both built using --with-platform=contrib/platform/lanl/macosx-
dynamic. For 1.3, I've added --disable-io-romio.
Any suggestions?
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/
ompi/mca/io/romio/romio/../..
rm=contrib/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" wrote:
Ralph,
I tried rolling back to 18513 but no luck. Steps:
$ ./auto
" 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" wrote:
Something seems to b
"Ralph Castain" 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" wrote:
Something seems to be broken in the trunk for MacOS X. I can run a 1
process job, but a >1 process job hangs. It was working a few days ago.
Greg
On Mar 5, 2008, at 7:38 AM, Jeff Squyres wrote:
On Mar 4, 2008, at 5:44 PM, Greg Watson wrote:
I certainly don't (nor anyone in PTP as far as I know) have the
resources to re-add functionality to OMPI, so unfortunately it
appears
that 1.2 will be the end of the line for PTP supp
s
is noted as a "bug" on our tracker, and I expect it will be
addressed prior
to releasing 1.3. I will ask that it be raised in priority.
I'll review what I had done and see about bringing it into the trunk
by the
end of the week.
Ralph
On 3/4/08 4:00 PM, "Greg Watson&q
reement, so it could
be 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 bee
es are always welcome!
IBM has signed the OMPI 3rd party contribution agreement, so it could
be 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 w
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
functiona
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
tw
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-e
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 sure
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 in
ot a known 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 --wit
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
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] Sign
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 MPI_
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:
http://www.open-mpi.org/software/ompi
process 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
dlopen'ing 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&
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 you can.
--
Tim Mattox - http://homepage.mac.com/tma
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 ort
On Feb 3, 2007, at 6:51 AM, Ralph Castain wrote:
On 2/2/07 8:44 AM, "Greg Watson" 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 daemon and the first ca
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 daemon and the first call to orte_init() that
can result in a bus error. We set the OMPI_MCA_universe and
OMPI_MCA_orte_univ_exist env
On Jan 30, 2007, at 9:39 AM, Ralph H Castain wrote:
On 1/30/07 9:24 AM, "Greg Watson" 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 debugged. We use spawn() t
y to do that right
now. The
ORTE 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" wrote:
On 1/29/07 5:57 PM, "Greg Watson" wrote:
Ralph,
On Jan 29, 2007,
Ralph,
On Jan 29, 2007, at 11:10 AM, Ralph H Castain wrote:
On 1/29/07 10:20 AM, "Greg Watson" wrote:
No, we have always called query() first, just after orte_init().
Since query() has never required a job id before, this used to work.
I think the call was required to kick th
On Jan 29, 2007, at 6:47 AM, Ralph H Castain wrote:
On 1/27/07 9:37 AM, "Greg Watson" wrote:
There are two more interfaces that have changed:
1. orte_rds.query() now takes a job id, whereas in 1.2b1 it didn't
take any arguments. I seem to remember that I call this to
, 2007, at 6:51 AM, Ralph Castain wrote:
On 1/26/07 11:36 PM, "Greg Watson" 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 removed. New user
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 gettin
On Jan 22, 2007, at 9:48 AM, Ralph H Castain wrote:
On 1/22/07 9:39 AM, "Greg Watson" 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 understand the issue wi
On Jan 22, 2007, at 9:48 AM, Ralph H Castain wrote:
On 1/22/07 9:39 AM, "Greg Watson" 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 understand the issue wi
1 - 100 of 144 matches
Mail list logo
