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 t

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 like the right solution.

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

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

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 nod

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 9:4

[OMPI devel] new plpa

I have the new PLPA merged down to a local copy of my trunk. It involves some autogen-worthy changes, so I'll hold off committing it until tonight. -- Jeff Squyres Cisco Systems

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

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

[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] getting config.guess/config.sub from upstream

Done -- thanks! https://svn.open-mpi.org/trac/ompi/changeset/17695 https://svn.open-mpi.org/trac/ompi/ticket/1226 On Mar 4, 2008, at 3:45 PM, Ralf Wildenhues wrote: Hello, Please note that the CVS repo for config.guess and config.sub is outdated, development has moved to use git. ompi_trunk/

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 Ral

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 o

Re: [OMPI devel] Fwd: OpenMPI changes

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 supported versions. As I mentioned to Ralph, I don't follow your developer discussions closely enough to unders

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 usuall

Re: [OMPI devel] Fwd: OpenMPI changes

Yeah, the problem we had in the past was: 1. something would trigger in the system - e.g., a particular job state was reached. This would cause us to execute a callback function via the GPR 2. the callback function would take some action. Typically, this involved sending out a message or calling

Re: [OMPI devel] Fwd: OpenMPI changes

Ralph, Looking at PTP, the only thing we need is to query the process information (PID, rank, node) when the job is created. Perhaps if only queries are allowed from callbacks then recursion would be eliminated? If you can get this functionality into your new interface and back in the tru

[OMPI devel] PLPA update: #@$!@#$

My apologies; apparently the SVN merge of PLPA somehow didn't work properly. The next time you "svn up", you'll get a conflict warning about opal/mca/paffinity/linux/plpa already existing. Do this to fix the problem: cd path-to-your-ompi-checkout svn up # see warning rm -rf opal/mca/paffi

Re: [OMPI devel] Fwd: OpenMPI changes

I'll try to get the code into the trunk before I go on vacation for a week on Fri. If not, I'll let you know and get it the week I get back (3/17). Basically, all I do is define an event in our event library that "fires" to send a message to you when the defined trigger occurs. If that is all you

Re: [OMPI devel] PLPA update: #@$!@#$

Never mind; this commit didn't work at all. I'm going to back it out. :-( On Mar 4, 2008, at 7:25 PM, Jeff Squyres wrote: My apologies; apparently the SVN merge of PLPA somehow didn't work properly. The next time you "svn up", you'll get a conflict warning about opal/mca/paffinity/linux/pl

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

[OMPI devel] Orte cleanup

I noticed that the new release of orte is not as good as it used to be to cleanup the mess left by crashed/aborted mpi processes. Recently We have been experiencing a lot of zombie or live locked processes running on the cluster nodes and disturbing following experiments. I didn't really ha

[OMPI devel] plpa upgrade

I am now reasonable sure that the trunk plpa upgrade has been completed successfully. You will still need to remove the old "plpa" directory when you "svn up": cd path/to/your/ompi/checkout rm -rf opal/mca/paffinity/linux/plpa svn up That shouldn't be necessary, but apparently I borked up s

[OMPI devel] Parallel debugger integration

Per the teleconference today: Because of the PLPA integration debacle tonight, I didn't get the new MPI handle debugging and totalview message queue bootstrapping stuff merged in today. So please hold off on any testing of that stuff for another day or two. I'll update when I get that stu