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"

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

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

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

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

[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

[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,

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

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

[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

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

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

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

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

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

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

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

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 > >

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)

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

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

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

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

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 >

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

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

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",

[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

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?

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

[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: