Re: [OMPI devel] ompi_info "developer warning"

Fine with me - I don’t care so long as we get rid of the annoying “warning” > On Jun 5, 2017, at 6:51 AM, George Bosilca wrote: > > I do care a little as the default size for most terminal is still 80 chars. I > would prefer your second choice where we replace "disabled" by "-" to losing > in

Re: [OMPI devel] ompi_info "developer warning"

I added the change to https://github.com/open-mpi/ompi/pull/3651 . We’ll just have to hope that people intuitively understand that “-“ means “disabled”. > On Jun 5, 2017, at 7:01 AM, r...@open-mpi.org wrote: > > Fine with me - I don’t care so long as

Re: [OMPI devel] ompi_info "developer warning"

I do care a little as the default size for most terminal is still 80 chars. I would prefer your second choice where we replace "disabled" by "-" to losing information on the useful part of the message. George. On Mon, Jun 5, 2017 at 9:45 AM, wrote: > George, > > > > it seems today the limit i

Re: [OMPI devel] ompi_info "developer warning"

George, it seems today the limit is more something like max 24 + max 56. we can keep the 80 character limit (i have zero opinion on that) and move to max 32 + max 48 for example. an other option is to replace "(disabled) " with something more compact "(-) " or even "- " Cheers, Gilles

Re: [OMPI devel] ompi_info "developer warning"

So we are finally getting rid of the 80 chars per line limit? George. On Sun, Jun 4, 2017 at 11:23 PM, r...@open-mpi.org wrote: > Really? Sigh - frustrating. I’ll change itas it gets irritating to keep > get this warning. > > Frankly, I find I’m constantly doing --all because otherwise I ha

Re: [OMPI devel] ompi_info "developer warning"

Really? Sigh - frustrating. I’ll change itas it gets irritating to keep get this warning. Frankly, I find I’m constantly doing --all because otherwise I have no earthly idea how to find what I’m looking for anymore... > On Jun 4, 2017, at 7:25 PM, Gilles Gouaillardet wrote: > > Ralph, > >

Re: [OMPI devel] ompi_info "developer warning"

Ralph, in your environment, pml/monitoring is disabled. so instead of displaying "MCA pml monitoring", ompi_info --all displays "MCA (disabled) pml monitoring" which is larger than 24 characters. fwiw, you can observe the same behavior with OMPI_MCA_sharedfp=^lockedfile ompi_info --all on

[OMPI devel] ompi_info "developer warning"

I keep seeing this when I run ompi_info --all: ** *** DEVELOPER WARNING: A field in ompi_info output is too long and *** will appear poorly in the prettyprint output. *** *** Value: "MCA (disabled) pml monitoring" ***

Re: [OMPI devel] .ompi_info dependency files

It is a vestige from a epoch where our shared library symbols were loaded in the RTLD_GLOBAL mode. I support your proposal to scrap it out. George. On Tue, Apr 7, 2015 at 1:41 PM, Nathan Hjelm wrote: > > I am working on rewriting some of the MCA component open code to delay > dlclose until o

[OMPI devel] .ompi_info dependency files

I am working on rewriting some of the MCA component open code to delay dlclose until opal_util_finalize () and I ran into something interesting. Open MPI supports component dependency files ending in .ompi_info. These files can be used to describe dependencies between mca components. This feature

Re: [OMPI devel] ompi_info not Giving Complete Output

Ah, I see. Thanks a lot guys. Kevin -- *Kevin A. Brown* *|* Tokyo Institute of Technology *|* *E-mail*: brown.k...@titech.ac.jp On Tue, May 27, 2014 at 3:06 AM, Jeff Squyres (jsquyres) wrote: > Or use --all. > > > On May 26, 2014, at 10:21 AM, Ralph Castain wrote:

Re: [OMPI devel] ompi_info not Giving Complete Output

Or use --all. On May 26, 2014, at 10:21 AM, Ralph Castain wrote: > Try adding "--level 9" to the cmd line. It's a new "feature" to try and > reduce the volume of data being thrown at the user as the majority of params > are frequently of use only to us developers > > On May 26, 2014, at 7:14

Re: [OMPI devel] ompi_info not Giving Complete Output

Try adding "--level 9" to the cmd line. It's a new "feature" to try and reduce the volume of data being thrown at the user as the majority of params are frequently of use only to us developers On May 26, 2014, at 7:14 AM, Kevin Brown wrote: > Greetings, > > I've just noticed that ompi_info (O

[OMPI devel] ompi_info not Giving Complete Output

Greetings, I've just noticed that ompi_info (Open MPI v. 1.8.1) is not giving a complete listing when ran with the following options: rc000:~ > ~/opt/openmpi-1.8.1-base/bin/ompi_info --param all all MCA btl: parameter "btl_tcp_if_include" (current value: "",

Re: [OMPI devel] ompi_info

Actually, the compromise was listed in my original mail: 2a. Fair enough. The long-standing ompi_info behavior precedent alone is probably enough to warrant re-thinking the new ompi_info behavior. Nathan will implement a compromise (that George was ok with when I talked on the phone with hi

Re: [OMPI devel] ompi_info

Jeff is indeed correct, the compromise we reached was to default to the historical behavior of showing only the parameters of selected components and have an option to show everything else. George. PS: Shouldn't "ompi_info --param all all" be identical to "ompi_info --all"? On Aug 27, 2013,

Re: [OMPI devel] ompi_info

On Aug 27, 2013, at 3:13 PM, Nathan Hjelm wrote: >>> 1a. ompi_info has a *very long-standing precedent* behavior of using >>> MCA params to exclude the display of components (and their >>> params). Users have come to rely on this behavior to test that OMPI is >>> honoring their $HOME/.openmp

Re: [OMPI devel] ompi_info

On Tue, Aug 27, 2013 at 06:57:09PM +0200, George Bosilca wrote: > > On Jul 19, 2013, at 17:57 , Jeff Squyres (jsquyres) > wrote: > > > I've now talked to both George and Nathan. Let me summarize for the web > > archives / community: > > > > 1. There are two main points of contention: > > >

Re: [OMPI devel] ompi_info

On Tue, Aug 27, 2013 at 06:57:09PM +0200, George Bosilca wrote: > > On Jul 19, 2013, at 17:57 , Jeff Squyres (jsquyres) > wrote: > > > I've now talked to both George and Nathan. Let me summarize for the web > > archives / community: > > > > 1. There are two main points of contention: > > >

Re: [OMPI devel] ompi_info

On Jul 19, 2013, at 17:57 , Jeff Squyres (jsquyres) wrote: > I've now talked to both George and Nathan. Let me summarize for the web > archives / community: > > 1. There are two main points of contention: > > 1a. ompi_info has a *very long-standing precedent* behavior of using > MCA para

Re: [OMPI devel] ompi_info

I've now talked to both George and Nathan. Let me summarize for the web archives / community: 1. There are two main points of contention: 1a. ompi_info has a *very long-standing precedent* behavior of using MCA params to exclude the display of components (and their params). Users have com

Re: [OMPI devel] ompi_info

George and I talked about this on the phone; I understand his questions better now. Nathan and I will get together and work through his questions and come back to everyone with some answers / proposals. On Jul 19, 2013, at 9:27 AM, George Bosilca wrote: > > My point is the following. I favo

Re: [OMPI devel] ompi_info

My point is the following. I favor consistent behaviors and I'm always in favor of respecting the configuration files. ALWAYS like in the word that mean all cases without exception. Thus, by default, ompi_info as any other component of the Open MPI infrastructure MUST read the configuration fil

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 11:50 AM, George Bosilca wrote: > How is this part of the code validated? It might capitalize on some type of > "trust". Unfortunately … I have no such notion. Not sure what you're asking here. > I would rather take the path of the "least astonishment", a __consistent__ >

Re: [OMPI devel] ompi_info

On Thu, Jul 18, 2013 at 05:50:40PM +0200, George Bosilca wrote: > On Jul 18, 2013, at 17:07 , Nathan Hjelm wrote: > > > This was discussed in depth before the MCA rewrite came into the trunk. > > There are only two cases where we load and register all the available > > components: ompi_info, an

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 17:07 , Nathan Hjelm wrote: > This was discussed in depth before the MCA rewrite came into the trunk. There > are only two cases where we load and register all the available components: > ompi_info, and MPI_T_init_thread(). The normal MPI case does not have this > behavior

Re: [OMPI devel] ompi_info

On Thu, Jul 18, 2013 at 08:33:37AM -0700, Ralph Castain wrote: > > On Jul 18, 2013, at 8:17 AM, "David Goodell (dgoodell)" > wrote: > > > On Jul 18, 2013, at 9:53 AM, Ralph Castain wrote: > > > >> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) > >> wrote: > >> > >>> On Jul 18, 2013,

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 8:17 AM, "David Goodell (dgoodell)" wrote: > On Jul 18, 2013, at 9:53 AM, Ralph Castain wrote: > >> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) >> wrote: >> >>> On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: >>> That's a good point, and a bad behavio

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 9:53 AM, Ralph Castain wrote: > On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) > wrote: > >> On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: >> >>> That's a good point, and a bad behavior. IIRC, it results from the MPI >>> Forum's adoption of the MPI-T requireme

Re: [OMPI devel] ompi_info

On Thu, Jul 18, 2013 at 07:53:35AM -0700, Ralph Castain wrote: > > On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) > wrote: > > > On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: > > > >> That's a good point, and a bad behavior. IIRC, it results from the MPI > >> Forum's adoption of t

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) wrote: > On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: > >> That's a good point, and a bad behavior. IIRC, it results from the MPI >> Forum's adoption of the MPI-T requirement that stipulates we must allow >> access to all control an

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 15:06 , Ralph Castain wrote: I think ompi_info has always shown all the variables despite what you have the selection variable set (at least in some cases). We now just display everything in all cases. An additional benefit to the updated code is that i

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: > That's a good point, and a bad behavior. IIRC, it results from the MPI > Forum's adoption of the MPI-T requirement that stipulates we must allow > access to all control and performance variables at startup so they can be > externally seen/man

Re: [OMPI devel] ompi_info

On Jul 18, 2013, at 5:46 AM, George Bosilca wrote: > On Jul 17, 2013, at 20:15 , "Jeff Squyres (jsquyres)" > wrote: > >> On Jul 17, 2013, at 12:16 PM, Nathan Hjelm wrote: >> >>> As Ralph suggested you need to pass the --level or -l option to see all the >>> variables. --level 9 will print

Re: [OMPI devel] ompi_info

On Jul 17, 2013, at 20:15 , "Jeff Squyres (jsquyres)" wrote: > On Jul 17, 2013, at 12:16 PM, Nathan Hjelm wrote: > >> As Ralph suggested you need to pass the --level or -l option to see all the >> variables. --level 9 will print everything. If you think there are variables >> everyday users

Re: [OMPI devel] ompi_info

On Jul 17, 2013, at 12:16 PM, Nathan Hjelm wrote: > As Ralph suggested you need to pass the --level or -l option to see all the > variables. --level 9 will print everything. If you think there are variables > everyday users should see you are welcome to change them to OPAL_INFO_LVL_1. > We are

Re: [OMPI devel] ompi_info

On Wed, Jul 17, 2013 at 03:04:06AM +0200, George Bosilca wrote: > I would like to question the choice for the new ? spartan ompi_info output? I > would not mind restoring the default behavior, aka. have a verbose "--all", > instead of some [random] MCA params. As Ralph suggested you need to pass

Re: [OMPI devel] ompi_info

On Jul 16, 2013, at 6:04 PM, George Bosilca wrote: > I would like to question the choice for the new … spartan ompi_info output? I won't debate the logic - I'll leave that to Jeff and Nathan > I would not mind restoring the default behavior, aka. have a verbose "--all", > instead of some [ran

[OMPI devel] ompi_info

I would like to question the choice for the new … spartan ompi_info output? I would not mind restoring the default behavior, aka. have a verbose "--all", instead of some [random] MCA params. Btw, something is wrong i the following output. I have an "btl = sm,self" in my .openmpi/mca-params.conf

Re: [OMPI devel] ompi_info requesting CPUs?

Ralph Castain wrote: does it exist in 1.3.4? Yes, e.g., 22103 and 22104. if so, it was a trivial change - can't see why it couldn't be added. On Oct 20, 2009, at 3:53 AM, Terry Dontje wrote: Not that I want to delay 1.3.4 anymore than it has been but this seems like a possible blocker.

Re: [OMPI devel] ompi_info requesting CPUs?

does it exist in 1.3.4? if so, it was a trivial change - can't see why it couldn't be added. On Oct 20, 2009, at 3:53 AM, Terry Dontje wrote: Not that I want to delay 1.3.4 anymore than it has been but this seems like a possible blocker. Can this be CMR'd for 1.3.4 or is this truly a 1.4

Re: [OMPI devel] ompi_info requesting CPUs?

Not that I want to delay 1.3.4 anymore than it has been but this seems like a possible blocker. Can this be CMR'd for 1.3.4 or is this truly a 1.4 CMR? --td Ralph Castain wrote: Fixed in r22111 Thanks On Oct 19, 2009, at 8:13 PM, Eugene Loh wrote: Somewhere between r22090 and r22109, ompi

Re: [OMPI devel] ompi_info requesting CPUs?

Fixed in r22111 Thanks On Oct 19, 2009, at 8:13 PM, Eugene Loh wrote: Somewhere between r22090 and r22109, ompi_info started (erroneously) requesting CPUs. E.g., r22090 is good: % ompi_info | grep Open MPI: Open MPI: 1.7a1r22090 But r22109 is bad: % ompi_info | grep Open MP

[OMPI devel] ompi_info requesting CPUs?

Somewhere between r22090 and r22109, ompi_info started (erroneously) requesting CPUs. E.g., r22090 is good: % ompi_info | grep Open MPI: Open MPI: 1.7a1r22090 But r22109 is bad: % ompi_info | grep Open MPI: ---