Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

2014-07-23 Thread Ralph Castain
I agree with the goal - we'll have to work this out at a later time. One key will be maintaining a memory-efficient mapping of opal_identifier to an RTE identifier, which typically requires some notion of launch grouping and rank within that grouping. On Jul 23, 2014, at 7:36 PM, George

Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

2014-07-23 Thread George Bosilca
A BTL should be completely agnostic to the notions of vpid and jobid. Unfortunately, as you mentioned, some of the BTLs are relying on this information in diverses ways. - If they rely for output purposes, this is a trivial matter as a BTL is supposed to rely upward any error and some upper

Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

2014-07-23 Thread Ralph Castain
Sounds reasonable. However, keep in mind that some BTLs actually require the notion of a jobid and rank-within-that-job. If the current ones don't, I assure you that at least one off-trunk one definitely does Some of the MTL's, of course, definitely rely on those fields. On Jul 23, 2014, at

Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

2014-07-23 Thread Jeff Squyres (jsquyres)
Sweet; I'll have a look at all of that -- thanks. On Jul 23, 2014, at 10:15 PM, George Bosilca wrote: > I was struggling with a similar issue while trying to fix the OpenIB > compilation. And I choose to implement a different approach, which does not > require knowledge

Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

2014-07-23 Thread George Bosilca
I was struggling with a similar issue while trying to fix the OpenIB compilation. And I choose to implement a different approach, which does not require knowledge of what’s inside opal_process_name_t. Look in opal/util/proc.h. You should be able to use: opal_process_name_vpid and

Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

2014-07-23 Thread Ralph Castain
You should be able to memcpy it to an ompi_process_name_t and then extract it as usual On Jul 23, 2014, at 6:51 PM, Jeff Squyres (jsquyres) wrote: > George -- > > Is there a way to get the MPI_COMM_WORLD rank of an opal_process_name_t? > > I am currently outputting some

Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

2014-07-23 Thread Jeff Squyres (jsquyres)
George -- Is there a way to get the MPI_COMM_WORLD rank of an opal_process_name_t? I am currently outputting some information about peer processes in the usnic BTL to include the peer's VPID, which is the MCW rank. I'll be sad if that goes away... On Jul 15, 2014, at 2:06 AM, George Bosilca

[OMPI devel] 1.8.2rc2 ready for test

2014-07-23 Thread Ralph Castain
Usual place: http://www.open-mpi.org/software/ompi/v1.8/ Please test and report problems by Wed July 30 Thanks Ralph

Re: [OMPI devel] barrier before calling del_procs

2014-07-23 Thread George Bosilca
My understanding is that both of these clauses are based on the fact that there are ongoing communications between two processes when one of them decide to shut down. From an MPI perspective, I can hardly see a case where this is legit. George. On Wed, Jul 23, 2014 at 8:33 AM, Yossi Etigin

Re: [OMPI devel] Annual SVN account maintenance

2014-07-23 Thread Jeff Squyres (jsquyres)
On Jul 23, 2014, at 11:02 AM, Ralph Castain wrote: > Just a little confusing here as some of these folks have changed > organizations, some of the orgs have dropped out of sight, etc. So it isn't > entirely clear who owns what on your chart. Note that the chart I included

Re: [OMPI devel] Annual SVN account maintenance

2014-07-23 Thread Joshua Ladd
Done. On Wed, Jul 23, 2014 at 11:02 AM, Ralph Castain wrote: > Just a little confusing here as some of these folks have changed > organizations, some of the orgs have dropped out of sight, etc. So it isn't > entirely clear who owns what on your chart. > > Looking at your

Re: [OMPI devel] Annual SVN account maintenance

2014-07-23 Thread Ralph Castain
Just a little confusing here as some of these folks have changed organizations, some of the orgs have dropped out of sight, etc. So it isn't entirely clear who owns what on your chart. Looking at your lists, it is full of people who haven't been involved with OMPI for many years. So I'd say

[OMPI devel] Annual SVN account maintenance

2014-07-23 Thread Jeff Squyres (jsquyres)
It is that time again -- it's time to clean house of SVN write access accounts. SHORT VERSION = Edit the wiki to preserve your organization's SVN accounts by COB, Thursday, July 31, 2014: https://svn.open-mpi.org/trac/ompi/wiki/2014-SVN-summer-cleaning If you don't indicate

Re: [OMPI devel] v1.8 - compile/dist problem

2014-07-23 Thread Mike Dubman
nope, we use git. it passed on rhel 6.x, failed on ubuntu/debian/fedora and rhel 7.x On Wed, Jul 23, 2014 at 4:03 PM, Jeff Squyres (jsquyres) wrote: > Mike -- > > Are you having the same jenkins problem we ran into yesterday? If so, > it's a simple fix: > >

Re: [OMPI devel] v1.8 - compile/dist problem

2014-07-23 Thread Bert Wesarg
Noticed by the VT guys. On 07/23/2014 03:01 PM, Mike Dubman wrote: CC libvt_mpi_la-vt_iowrap_helper.lo CC libvt_mpi_la-vt_libwrap.lo CC libvt_mpi_la-vt_mallocwrap.lo CC libvt_mpi_la-vt_mpifile.lo make[6]: Entering directory

Re: [OMPI devel] v1.8 - compile/dist problem

2014-07-23 Thread Jeff Squyres (jsquyres)
Mike -- Are you having the same jenkins problem we ran into yesterday? If so, it's a simple fix: http://www.open-mpi.org/community/lists/devel/2014/07/15211.php On Jul 23, 2014, at 9:01 AM, Mike Dubman wrote: > > CC libvt_mpi_la-vt_iowrap_helper.lo >

[OMPI devel] v1.8 - compile/dist problem

2014-07-23 Thread Mike Dubman
CC libvt_mpi_la-vt_iowrap_helper.lo CC libvt_mpi_la-vt_libwrap.lo CC libvt_mpi_la-vt_mallocwrap.lo CC libvt_mpi_la-vt_mpifile.lo make[6]: Entering directory '/var/tmp/OFED_topdir/BUILD/openmpi-1.8.2rc2/ompi/contrib/vt/vt/tools/vtunify/mpi' ln -s