Easier than I thought...done in r21147
Let me know if that meets your needs
Ralph
On Mon, May 4, 2009 at 9:42 AM, Ralph Castain wrote:
> Should be doable
>
> Since the output was going to stderr, we just let it continue to do so and
> tagged it. I think I can redirect it when doing xml tag
Should be doable
Since the output was going to stderr, we just let it continue to do so and
tagged it. I think I can redirect it when doing xml tagging as that is
handled as a separate case - shouldn't be too hard to do.
On Mon, May 4, 2009 at 9:29 AM, Greg Watson wrote:
> Ralph,
> I did fi
Ralph,
I did find another issue in 1.3 though. It looks like with the -xml
option you're sending output tagged with to stderr, whereas
it would probably be better if everything was sent to stdout.
Otherwise it's necessary to parse the stderr stream separately.
Greg
On May 1, 2009, at 10
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 --display-map hostname
Interesting - I'm not seeing this behavior:
graywolf54:trunk rhc$ mpirun -n 3 --xml --display-map hostname
graywolf54.lanl.gov
graywolf54.lanl.gov
graywolf54.lanl.gov
graywolf54:trunk rhc$
Can you tell me more about when you see this? Note that the display-m
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 sent to stderr (wrapped in xml
> tags). Was this by design? In my
Looks good now. Thanks!
Greg
On Jan 20, 2009, at 12:00 PM, Ralph Castain wrote:
I'm embarrassed to admit that I never actually implemented the xml
option for tag-output...this has been rectified with r20302.
Let me know if that works for you - sorry for confusion.
Ralph
On Jan 20, 2009,
I'm embarrassed to admit that I never actually implemented the xml
option for tag-output...this has been rectified with r20302.
Let me know if that works for you - sorry for confusion.
Ralph
On Jan 20, 2009, at 8:08 AM, Greg Watson wrote:
Ralph,
The encapsulation is not quite right yet. I
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 to xml and non-xml situations.
I don't think there's any reason we'd want stdout/err not to be
encapsulated, so forcing tag-output makes sense.
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 to xml and non-xml situations.
If you like, I
You need to add --tag-output - this is a separate option as it applies
both to xml and non-xml situations.
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 en
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_nodenames 1 -xml -display-map -np 5 /
Users/greg/Documents/workspace1/testMPI/Debug/testMPI
Fixed in r20288. Thanks for the catch.
On Jan 16, 2009, at 2:04 PM, Greg Watson wrote:
FYI, if I configure with --with-platform=contrib/platform/lanl/
macosx-dynamic the build succeeds.
Greg
On Jan 16, 2009, at 1:08 PM, Jeff Squyres wrote:
References: <78c4b4d7-d9bc-4268-97cf-8cbad...@
FYI, if I configure with --with-platform=contrib/platform/lanl/macosx-
dynamic the build succeeds.
Greg
On Jan 16, 2009, at 1:08 PM, Jeff Squyres wrote:
References: <78c4b4d7-d9bc-4268-97cf-8cbad...@computer.org> > <9317bd55-13a2-44be-bcc0-3e42e2322...@computer.org> <5cb48a5d-1ce3-48f7-889
References: <78c4b4d7-d9bc-4268-97cf-8cbad...@computer.org> <9317bd55-13a2-44be-bcc0-3e42e2322...@computer.org>
<5cb48a5d-1ce3-48f7-8890-c99239b0a...@lanl.gov> <22ebe824--47f1-a954-8b54536bf...@computer.org>
<6dda0348-96b4-4e3f-91b4-490631cfe...@computer.org>
<460591d2-bd7b-43ca-9b1
When I try to build trunk, it fails with:
i_f77.lax/libmpi_f77_pmpi.a/pwin_unlock_f.o .libs/libmpi_f77.lax/
libmpi_f77_pmpi.a/pwin_wait_f.o .libs/libmpi_f77.lax/libmpi_f77_pmpi.a/
pwtick_f.o .libs/libmpi_f77.lax/libmpi_f77_pmpi.a/
pwtime_f.o ../../../ompi/.libs/libmpi.0.0.0.dylib /usr/local/
Okay, it is in the trunk 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 Watso
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 to do - note that the resolve messages are
associated with the specific hostname, not the overall map:
Here is what I was able to do - note that the resolve messages are
associated with the specific hostname, not the overall map:
Will that work for you? If you like, I can remove the name= field from
the no
We -may- be able to do a more formal XML output at some point. The
problem will be the natural interleaving of stdout/err from the
various procs due to the async behavior of MPI. Mpirun receives
fragmented output in the forwarding system, limited by the buffer
sizes and the amount of data w
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 is all that will ever be possible with 1.3, then you may
as well leave as-is and we will attempt to clean it up in Eclipse. It
would be nice if a future version of
Hmmm...well, I can't do either for 1.3.0 as it is departing this
afternoon.
The first option would be very hard to do. I would have to expose the
display-map option across the code base and check it prior to printing
anything about resolving node names. I guess I should ask: do you only
w
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). So rather than:
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 be easier in the future if we could test/debug this in the
trunk, though. Otherwise, the CMR procedure will fall behind and a
fix might miss a
Working its way around the CMR process now.
Might be easier in the future if we could test/debug this in the
trunk, though. Otherwise, the CMR procedure will fall behind and a fix
might miss a release window.
Anyway, hopefully this one will make the 1.3.0 release cutoff.
Thanks
Ralph
On D
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] resolved="Jarrah.watson.ibm.com">
For some reason each line is prefixed with "[...]", any idea why this
is? Also the end tag should be "/>" not ">".
Thanks,
It slipped thru the cracks - will be in rc2.
Thanks for the reminder!
Ralph
On Dec 2, 2008, at 2:03 PM, Greg Watson wrote:
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
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 in a
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 in a
few days.
I implemented it as another MCA param "orte_show_resolved_nodenames"
so you can
Yo Greg
This is in the trunk as of r20032. I'll bring it over to 1.3 in a few
days.
I implemented it as another MCA param "orte_show_resolved_nodenames"
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,
I guess the issue for us is that we will have to run two commands to
get the information we need. One to get the configuration information,
such as version and MCA parameters, and one to get the host
information, whereas it would seem more logical that this should all
be available
Hmmm...just to be sure we are all clear on this. The reason we
proposed to use mpirun is that "hostfile" has no meaning outside of
mpirun. That's why ompi_info can't do anything in this regard.
We have no idea what hostfile the user may specify until we actually
get the mpirun cmd line. The
Ralph,
It seems a little strange to be using mpirun for this, but barring
providing a separate command, or using ompi_info, I think this would
solve our problem.
Thanks,
Greg
On Oct 17, 2008, at 10:46 AM, Ralph Castain wrote:
Sorry for delay - had to ponder this one for awhile.
Jeff an
Sorry for delay - had to ponder this one for awhile.
Jeff and I agree that adding something to ompi_info would not be a
good idea. Ompi_info has no knowledge or understanding of hostfiles,
and adding that capability to it would be a major distortion of its
intended use.
However, we think
Hi Ralph,
We've been discussing this back and forth a bit internally and don't
really see an easy solution. Our problem is that Eclipse is not
running on the head node, so gethostbyname will not necessarily
resolve to the same address. For example, the hostfile might refer to
the head nod
Sorry for delay - was on vacation and am now trying to work my way
back to the surface.
I'm not sure I can fix this one for two reasons:
1. In general, OMPI doesn't really care what name is used for the
node. However, the problem is that it needs to be consistent. In this
case, ORTE has al
We always output the entire map, so you'll see the parent procs as
well as the child
On Sep 16, 2008, at 12:52 PM, Greg Watson wrote:
Hi Ralph,
No I'm happy to get a map at the beginning and at every spawn. Do
you send the whole map again, or only an update?
Regards,
Greg
On Sep 11, 2
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 for
us as we need to be able to match the two, and since we're not
necessarily runni
> thanks, applied
oops, replied to the wrong message ;)
thanks, applied
Hi Ralph,
No I'm happy to get a map at the beginning and at every spawn. Do you
send the whole map again, or only an update?
Regards,
Greg
On Sep 11, 2008, at 9:09 AM, Ralph Castain wrote:
It already somewhat does. If you use --display-map at mpirun, you
automatically get display-map whe
It already somewhat does. If you use --display-map at mpirun, you
automatically get display-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 de
Not in that regard, depending upon what you mean by "recently". The
only changes I am aware of wrt nodes consisted of some changes to the
order in which we use the nodes when specified by hostfile or -host,
and a little #if protectionism needed by Brian for the Cray port.
Are you seeing thi
43 matches
Mail list logo
