Re: [OMPI devel] Annual Open MPI membership review, and Git repo permissions review

Still waiting on the following organizations to update their list of committers in this spreadsheet: * Mellanox * U. Houston * AMD * ORNL * Oracle * HLRS * HFT Stuttgart

Re: [OMPI devel] 1.10.0 issue

Ignore me; I read your email wrong. You have "btl = ^usnic" commented out, and a line above it saying "if you need PSM2, then uncomment these...". Makes perfect sense. Sorry for the noise. > On Sep 4, 2015, at 12:00 PM, Jeff Squyres (jsquyres) > wrote: > > Michael: Wait, why are you disabl

Re: [OMPI devel] 1.10.0 issue

Michael: Wait, why are you disabling usnic? Please don't penalize usNIC because of Intel's PSM issues. > On Sep 4, 2015, at 9:29 AM, Ralph Castain wrote: > > Umm…why would USNIC depend on libpsm_infinipath?? Jeff or Dave - is that true? > > > >> On Sep 4, 2015, at 5:57 AM, Michal Schmidt

Re: [OMPI devel] 1.10.0 issue

Ralph: you might want to just advise RH to use --without-psm2. It's a little more direct / a little less convoluted than --enable-mca-no-build. > On Sep 4, 2015, at 10:51 AM, Ralph Castain wrote: > > Understood - for now, it appears RH has an acceptable solution by using the > MCA param, so

Re: [OMPI devel] 1.10.0 issue

Understood - for now, it appears RH has an acceptable solution by using the MCA param, so I see no need for further action until you complete the fix > On Sep 4, 2015, at 7:45 AM, Friedley, Andrew > wrote: > > The PSM2 MTL code I submitted to master, 1.10, and 2.x will auto-build if the > li

Re: [OMPI devel] 1.10.0 issue

The PSM2 MTL code I submitted to master, 1.10, and 2.x will auto-build if the library is detected in the system; I don't think that's been changed since. Feel free to disable the auto-build until we can get a PSM2 solution, but we'd much prefer not to outright remove the PSM2 MTL. Andrew > --

Re: [OMPI devel] 1.10.0 issue

A…thanks! > On Sep 4, 2015, at 6:52 AM, Michal Schmidt wrote: > > On 09/04/2015 03:29 PM, Ralph Castain wrote: >> Umm…why would USNIC depend on libpsm_infinipath?? Jeff or Dave - is that >> true? > > Indirectly, via libfabric. > > Michal > > > __

Re: [OMPI devel] 1.10.0 issue

On 09/04/2015 03:29 PM, Ralph Castain wrote: > Umm…why would USNIC depend on libpsm_infinipath?? Jeff or Dave - is that true? Indirectly, via libfabric. Michal

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

I think we already do, but I can check > On Sep 4, 2015, at 6:06 AM, Gilles Gouaillardet > wrote: > > iirc, hwloc can read input from an xml file. > if not already the case, should we provide a simple mechanism to tell hwloc > not to detect the topology from the os but from a config file. > fo

Re: [OMPI devel] 1.10.0 issue

Umm…why would USNIC depend on libpsm_infinipath?? Jeff or Dave - is that true? > On Sep 4, 2015, at 5:57 AM, Michal Schmidt wrote: > > On 09/03/2015 03:47 PM, Ralph Castain wrote: >> I guess I didn’t make it clear in my prior comment, so let me try >> again. I understand about dlopen and the f

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

iirc, hwloc can read input from an xml file. if not already the case, should we provide a simple mechanism to tell hwloc not to detect the topology from the os but from a config file. for example, if working on a new os and/or hardware, then manually generate the hwloc xml file on each node and do

Re: [OMPI devel] 1.10.0 issue

On 09/03/2015 03:47 PM, Ralph Castain wrote: > I guess I didn’t make it clear in my prior comment, so let me try > again. I understand about dlopen and the fix that George proposed - > we had internally discussed this as well. However, the questions that > raises are: > > 1. how does the distro (M

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

It sounds, then, like removing —without-hwloc will do no harm. At worst, hwloc might report inaccurate info, but that won’t stop us from running with appropriate cmd line options (e.g., to set the #slots and bind-to none). Unless there are any further concerns, I’ll prep the PR > On Sep 4, 201

Re: [OMPI devel] RFC: Remove the --enable-mpi-profile option

While it would take longer on the laptop, we don’t often build on laptops from bottom-up - i.e., we only have to run the full build operation when configury is changed. So I’d say go ahead and remove it > On Sep 4, 2015, at 12:49 AM, Gilles Gouaillardet wrote: > > Folks, > > Jeff and i have

[OMPI devel] no more cast away const

Folks, a bunch of C bindings have comments such as /* XXX -- CONST -- do not cast away const -- update mca/coll */ and that has been there for a long time. i made PR #839 https://github.com/open-mpi/ompi/pull/839 to fix this. the change is quite massive (270 files) since : - the C bindings had t

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Brice, I'm a developer of Fujitsu MPI for K computer and Fujitsu PRIMEHPC FX10/FX100 (SPARC-based CPU). Though I'm not familiar with the hwloc code and didn't know the issue reported by Gilles, I also would be able to help you to fix the issue. Takahiro Kawashima, MPI development team, Fujitsu

[OMPI devel] RFC: Remove the --enable-mpi-profile option

Folks, Jeff and i have been discussing the possibility of removing the --enable-mpi-profile option from ompi. (see https://github.com/open-mpi/ompi/pull/845 for the details) Removing this option would simplify the building process, and make it crystal clear that Fortran bindings call the C PM

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Thanks Brice, bottom line, even if hwloc is not fully ported, it should build and ompi should get something usable. in this case, i have no objection removing the --without-hwloc configure option. you can contact me off-list regarding the FX10 specific issue Cheers, Gilles On 9/4/2015 2:31

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Le 04/09/2015 00:36, Gilles Gouaillardet a écrit : > Ralph, > > just to be clear, your proposal is to abort if openmpi is configured > with --without-hwloc, right ? > ( the --with-hwloc option is not removed because we want to keep the > option of using an external hwloc library ) > > if I understa