Re: [OMPI devel] [RFC] Default hostfile MCA param

We have used '^' elsewhere to indicate not, so maybe just have the syntax be if you put '^' at the beginning of a line, that node is not used. So we could have: n0 n1 ^headnode n3 I understand the idea of having a flag to indicate that all nodes below a certain point should be ignored, but I

Re: [OMPI devel] [RFC] Default hostfile MCA param

On 3/4/08 5:51 AM, "Tim Prins" wrote: > We have used '^' elsewhere to indicate not, so maybe just have the > syntax be if you put '^' at the beginning of a line, that node is not used. > > So we could have: > n0 > n1 > ^headnode > n3 > That works for me and sounds

[OMPI devel] disabling vt by default

Per prior e-mails on this list, I finally got around to disabling VT builds by default this morning (https://svn.open-mpi.org/trac/ompi/changeset/17683 -- I committed before 9am Eastern, so it's, er, sorta/mostly before the US workday :p ). Once the VT configury stuff is incorporated into

[OMPI devel] make check failing

Hi, We have been having a problem lately with our MTT runs where make check would fail when mpi threads were enabled. Turns out the problem is that opal_init now calls opal_base_carto_select, which cannot find any carto modules since we have not done an install yet. So it returns a failure.

Re: [OMPI devel] make check failing

Carto select failing if it doesn't find any modules was called out in an earlier message (might have been a commit log) when we set an mca-no-build flag on that framework. This should probably be fixed - there are times when someone may not wish to build any carto modules. Is there some reason

Re: [OMPI devel] make check failing

I think another important question is: why is this related to threads? (i.e., why does it work in non-threaded builds) On Mar 4, 2008, at 9:44 AM, Ralph H Castain wrote: Carto select failing if it doesn't find any modules was called out in an earlier message (might have been a commit log)

Re: [OMPI devel] [RFC] Default hostfile MCA param

Tim Prins wrote: We have used '^' elsewhere to indicate not, so maybe just have the syntax be if you put '^' at the beginning of a line, that node is not used. So we could have: n0 n1 ^headnode n3 this would sound fine for me. I understand the idea of having a flag to indicate that all

Re: [OMPI devel] make check failing

Simple, because the test that eventually segfaults only runs if ompi is configured with threading. Otherwise it is a no-op. Tim Jeff Squyres wrote: I think another important question is: why is this related to threads? (i.e., why does it work in non-threaded builds) On Mar 4, 2008, at

[OMPI devel] [RFC] Reduce the number of tests run by make check

WHAT: Reduce the number of tests run by make check WHY: Some of the tests will not work properly until Open MPI is installed. Also, many of the tests do not really test anything. WHERE: See below. TIMEOUT: COB Friday March 14 DESCRIPTION: We have been having many problems with make check

[OMPI devel] suggested patch for mca-btl-openib-hca-params.ini

Here is a suggested patch for adding the QLogic QLE7240 and QLE7280 DDR HCA cards to the openib params file. I would like the MTU to default to 4K for these HCAs but I don't see any code using the ibv_port_attr.active_mtu field to limit the MTU to the active MTU. If you like, I can try to make a

Re: [OMPI devel] suggested patch for mca-btl-openib-hca-params.ini

Sounds good -- I don't remember who's on the schedule A for Qlogic, but I know that Christian Bell can commit. Do you need this for v1.2.6? We are literally rolling 1.2.6rc1 right *now*... On Mar 4, 2008, at 2:12 PM, Ralph Campbell wrote: Here is a suggested patch for adding the QLogic

[OMPI devel] Fwd: OpenMPI changes

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

[OMPI devel] getting config.guess/config.sub from upstream

Hello, Please note that the CVS repo for config.guess and config.sub is outdated, development has moved to use git. ompi_trunk/config/distscript.csh could be adjusted to pull from and likewise for config.sub.

Re: [OMPI devel] Fwd: OpenMPI changes

Greg -- I admit to being a bit puzzled here. Ralph sent around RFCs about these changes many months ago. Everyone said they didn't want this functionality -- it was seen as excess functionality that Open MPI didn't want or need -- so it was all removed. As such, I have to agree with

Re: [OMPI devel] Fwd: OpenMPI changes

It is buried deep-down in the thread, but I'll just reiterate it here. I have "restored" the ability to "subscribe" to changes in job, proc, and node state via OMPI's tool interface library. I have -not- checked this into the trunk yet, though, until the community has a chance to consider whether

Re: [OMPI devel] Fwd: OpenMPI changes

I don't have a problem using a different interface, assuming it's adequately supported and provides the functionality we need. I presume the recursive behavior you're referring to is calling OMPI interfaces from the callback functions. Any event-based system has this issue, and it is

[OMPI devel] documentation trac ticket type

I just added a "documentation" trac ticket type. Its intent is for user-visible changes that are worth documenting for the v1.3 release (this likely means the FAQ for the moment). Two obvious examples (that I just filed tickets for): - the new OMPI_* environment variables for indicating