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
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
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,
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:
>
>> T
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
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
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
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
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
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
.
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_
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
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
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
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
, 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
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
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
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 "&&
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 lik
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
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
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
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
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
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,
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
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
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
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
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
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 other
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
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
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
:-).
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
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
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
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
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, this
Oops, should have mentioned that this is 1.0.2 on MacOSX.
Greg
On Apr 19, 2006, at 5:15 PM, Greg Watson wrote:
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
Brian Barrett wrote:
On Apr 19, 2006, at 4:15 PM, Greg Watson wrote:
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
bably be next week before 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
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
In OpenMPI 1.0, I was able to get the PID's for each process by
querying the ORTE_PROCESS_PID_KEY. This no longer seems to work in
1.2. Can someone let me know how I can get hold of the PID's
regardless of the pls?
Greg
ORTE_PROC_PID_KEY. This one refers to the pid
assigned
by the launcher - the other refers to the pid reported by the
process from
its remote node.
Ralph
On 11/9/06 11:44 AM, "Greg Watson" wrote:
In OpenMPI 1.0, I was able to get the PID's for each process by
querying the ORTE_PROCES
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(&argc, &argv) corrupts the argc variable.
Repeat By:
1. Compile the following program using 'mpicc -g -o m
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] [0,0,0] ORTE_ERROR_LOG: Not available in
file ras_bjs.c at line 247
---
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 19, 2007, at 4:39 PM, Li-Ta Lo wrote:
On Fri, 2007-01-19 at 14:42 -0700, Greg Watson wrote:
The libraries required by the program are:
$ ldd x
librt.so.1 => /lib64/tls/librt.so.1 (0x2abc1000)
libbproc.so.4 => /usr/lib64/libbproc.so.4
(0x2a
need to add to your command line is:
-mca btl ^sm -mca mpi_preconnect_all 1
Ralph
On 1/22/07 8:02 AM, "Greg Watson" wrote:
On Jan 19, 2007, at 4:39 PM, Li-Ta Lo wrote:
On Fri, 2007-01-19 at 14:42 -0700, Greg Watson wrote:
The libraries required by the program are:
$ ldd x
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
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
, 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
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
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
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,
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
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 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
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
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
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&
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
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
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_
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
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
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
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
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
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,
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
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
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
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
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
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
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
"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:
" 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
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
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/../..
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?
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,
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
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
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
, 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
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
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
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
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
1 - 100 of 144 matches
Mail list logo
