Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Jeff Squyres (jsquyres)]

On May 6, 2013, at 10:39 PM, Ralph Castain  wrote:

> Could someone help me out a bit here:
> 
> * I'm unaware of any mechanism for "ignoring" an entire framework. Was 
> something added for that purpose?

It's been in autogen.pl for a while -- check out the end of 
mca_process_framework() in autogen.pl.

> * What "non-MCA" projects are in our repository? Everything appears to be 
> based on MCA plugins.
> 
> * Looking at Trac, we eliminated all project/config directories when we did 
> the OMPI-RTE abstraction. So what are we looping across at the end of autogen?

Yes, we did.  ORNL specifically asked me/Nathan off-list if they could add this 
loop in, because they have some off-trunk repos (e.g., STCI) that both still 
use the config/ directory stuff and have non-MCA projects.  I didn't see any 
harm in these things; e.g., the loop only adds -I if the directory exists.  
I.e., I saw it as being an attempt to be friendly to those who are trying to 
use our lower laters (ORTE and/or OPAL) with non-OMPI projects.  I thought this 
fit in well with the move-the-BTLs-down-to-OPAL philosophy.

That being said, if others disagree -- e.g., Ralph has a valid point: this is 
to help projects that are outside of our trunk -- let's discuss.  This will 
probably be a useful topic to discuss today on the teleconf.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] Fwd: Q: project based MCA param files

[Jeff Squyres (jsquyres)]

Given Ralph's questions about 
rhttps://svn.open-mpi.org/trac/ompi/changeset/28456, ORNL's second question to 
me/Nathan about MCA params is probably worth forwarding to the list -- see 
below.

Thoughts on this proposal?


Begin forwarded message:

> From: "Boehm, Swen" 
> Subject: Re: Q: project based MCA param files
> Date: May 3, 2013 5:03:43 PM EDT
> To: "Jeff Squyres (jsquyres)" 
> Cc: Nathan Hjelm , "Vallee, Geoffroy R." 
> , "Naughton III, Thomas J." 
> 
> Hi Jeff,
> 
> Here is a short description of the enhancement we would like to contribute.
> Let us know what you think.
> 
> The purpose of the suggested improvements is to enable "projects" to read
> MCA parameters from project specific locations. This enables the usage
> of OPAL and the MCA Frameworks outside the OpenMPI project without
> interfering with OpenMPI specific parameters and removes the need to 
> patch OPAL (e.g., to pick up params from different locations).
> 
> The possible scenarios would be the following:
> 
> a) adding the option to pick up a project specific mca-param.conf file
>   Example:
>$HOME/.mca/${project}-mca-param.conf
>and /etc/mca/${project}-mca-param.conf)
> 
> b) add the option to pick up the mca-param.conf file from a project specific
>   directory
>   Example:
>$HOME/.${project}/mca-param.conf
>and /etc/${project}/mca-param.conf
>and/or  /etc/${project}/${project}-mca-param.conf)
> 
> c) prefixing the mca param with the project name in the existing 
> mca-param.conf
>   file and therefore following the new MCA variable system naming scheme.
>   Example:
>mca_${project}_${framework}_${component}_${var_name}
> 
> The implementation has to be compatible with the current system, that is, 
> it should work as it does today without any added burden to the user. The
> suggested approach is to provide an addition to the MCA API (something like
> mca_base_add_config_file_path ()) to add lookup paths to the MCA system.
> This way additional files can be picked up for the MCA param parsing if
> needed.
> 
> To wrap it up:
> 1) Is the motivation clear?
> 2) Is it possible to implement the desired capability within a
>reasonable time and without changing the current behavior?
> 3) Does it line up with the planning / future capabilities?
> 4) Which of the above options (A, B, C) would you prefer?
> 
> -- 
> Swen Boehm  | Email: bo...@ornl.gov
> Oak Ridge National Laboratory  | Phone: +1 865-576-6125
> 
> 
> On Apr 26, 2013, at 7:50 PM, Thomas Naughton  wrote:
> 
>> Hi,
>> 
>> Ok, sounds good. We'll check on this next week and get back to you.
>> 
>> Thanks,
>> --tjn
>> 
>> _
>>  Thomas Naughton  naught...@ornl.gov
>>  Research Associate   (865) 576-4184
>> 
>> 
>> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
>> 
>>> Email would probably be easiest -- I will need to page in/refresh this area 
>>> of the code, anyway, so if you guys do the initial homework and submit some 
>>> ideas, that would probably be easiest (For me).  :-D
>>> 
>>> 
>>> On Apr 26, 2013, at 6:33 PM, Thomas Naughton 
>>> wrote:
>>> 
 Hi Jeff,
 
 We don't have one yet but we can code something up and submit a patch.
 
 If useful we could quickly sync up beforehand to ensure we are on the same 
 page.   Phone or email, whatever would be easiest.
 
 What do you think?
 --tjn
 
 _
 Thomas Naughton  naught...@ornl.gov
 Research Associate   (865) 576-4184
 
 
 On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
 
> I'm not aware of any plans to do this.
> 
> Do you guys have a patch to submit, perchance?  :-D
> 
> 
> On Apr 22, 2013, at 6:30 PM, Thomas Naughton  wrote:
> 
>> Hi Nathan & Jeff,
>> 
>> You guys have done some MCA updates lately and we were curious if there 
>> are
>> any plans or thoughts about an enhancement regarding MCA param files.
>> 
>> Briefly speaking, we were curious if there were plans for either having
>> project specific MCA param files, or having a generic mca param file that
>> would use the projects as part of the namespace.  I think an example 
>> would
>> help clarify.
>> 
>> We currently change things to have "$HOME/.stci/mca-params.conf".  This 
>> is
>> pretty much the only remaining modification we have for OPAL after recent
>> updates.  If there was a way to have something like
>> "$HOME/.${project}/mca-params.conf", or
>> "$HOME/.mca/${project}-mca-params.conf", it would remove this remaining 
>> customization we do to OPAL.
>> 
>> This sort of thing seems like it could

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Ralph Castain]

On May 7, 2013, at 6:19 AM, Jeff Squyres (jsquyres)  wrote:

> On May 6, 2013, at 10:39 PM, Ralph Castain  wrote:
> 
>> Could someone help me out a bit here:
>> 
>> * I'm unaware of any mechanism for "ignoring" an entire framework. Was 
>> something added for that purpose?
> 
> It's been in autogen.pl for a while -- check out the end of 
> mca_process_framework() in autogen.pl.

I see - you didn't mean "ignore the framework", you meant "ignore all 
components in this framework". The two are not the same thing. Ignoring the 
framework would mean that we were somehow going to skip the base as well, which 
couldn't possibly work. We've talked about that before and never could figure 
out how to null-out all the framework level functions.

> 
>> * What "non-MCA" projects are in our repository? Everything appears to be 
>> based on MCA plugins.
>> 
>> * Looking at Trac, we eliminated all project/config directories when we did 
>> the OMPI-RTE abstraction. So what are we looping across at the end of 
>> autogen?
> 
> Yes, we did.  ORNL specifically asked me/Nathan off-list if they could add 
> this loop in, because they have some off-trunk repos (e.g., STCI) that both 
> still use the config/ directory stuff and have non-MCA projects.  I didn't 
> see any harm in these things; e.g., the loop only adds -I if the directory 
> exists.  I.e., I saw it as being an attempt to be friendly to those who are 
> trying to use our lower laters (ORTE and/or OPAL) with non-OMPI projects.  I 
> thought this fit in well with the move-the-BTLs-down-to-OPAL philosophy.
> 
> That being said, if others disagree -- e.g., Ralph has a valid point: this is 
> to help projects that are outside of our trunk -- let's discuss.  This will 
> probably be a useful topic to discuss today on the teleconf.

I don't object to it being there as it is a "no-op" for us - there was just no 
explanation given as to why this was being done. So it looked like a patch 
based on an old version of the trunk.


> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Q: project based MCA param files

[Ralph Castain]

I believe we already have a way of defining where to get the default mca params:

ret = mca_base_var_register ("opal", "mca", "base", "param_files", "Path 
for MCA "
 "configuration files containing variable 
values",
 MCA_BASE_VAR_TYPE_STRING, NULL, 0, 0, 
OPAL_INFO_LVL_2,
 MCA_BASE_VAR_SCOPE_READONLY, 
&mca_base_var_files);


So wouldn't it be as easy as defining an envar? It's what we did when using the 
OMPI code with ORCM a couple of years ago, and we used it again for a recent 
project in Greenplum where the default mca param was specified in a different 
location than usual.


On May 7, 2013, at 6:28 AM, Jeff Squyres (jsquyres)  wrote:

> Given Ralph's questions about 
> rhttps://svn.open-mpi.org/trac/ompi/changeset/28456, ORNL's second question 
> to me/Nathan about MCA params is probably worth forwarding to the list -- see 
> below.
> 
> Thoughts on this proposal?
> 
> 
> Begin forwarded message:
> 
>> From: "Boehm, Swen" 
>> Subject: Re: Q: project based MCA param files
>> Date: May 3, 2013 5:03:43 PM EDT
>> To: "Jeff Squyres (jsquyres)" 
>> Cc: Nathan Hjelm , "Vallee, Geoffroy R." 
>> , "Naughton III, Thomas J." 
>> 
>> Hi Jeff,
>> 
>> Here is a short description of the enhancement we would like to contribute.
>> Let us know what you think.
>> 
>> The purpose of the suggested improvements is to enable "projects" to read
>> MCA parameters from project specific locations. This enables the usage
>> of OPAL and the MCA Frameworks outside the OpenMPI project without
>> interfering with OpenMPI specific parameters and removes the need to 
>> patch OPAL (e.g., to pick up params from different locations).
>> 
>> The possible scenarios would be the following:
>> 
>> a) adding the option to pick up a project specific mca-param.conf file
>>  Example:
>>   $HOME/.mca/${project}-mca-param.conf
>>   and /etc/mca/${project}-mca-param.conf)
>> 
>> b) add the option to pick up the mca-param.conf file from a project specific
>>  directory
>>  Example:
>>   $HOME/.${project}/mca-param.conf
>>   and /etc/${project}/mca-param.conf
>>   and/or  /etc/${project}/${project}-mca-param.conf)
>> 
>> c) prefixing the mca param with the project name in the existing 
>> mca-param.conf
>>  file and therefore following the new MCA variable system naming scheme.
>>  Example:
>>   mca_${project}_${framework}_${component}_${var_name}
>> 
>> The implementation has to be compatible with the current system, that is, 
>> it should work as it does today without any added burden to the user. The
>> suggested approach is to provide an addition to the MCA API (something like
>> mca_base_add_config_file_path ()) to add lookup paths to the MCA system.
>> This way additional files can be picked up for the MCA param parsing if
>> needed.
>> 
>> To wrap it up:
>> 1) Is the motivation clear?
>> 2) Is it possible to implement the desired capability within a
>>   reasonable time and without changing the current behavior?
>> 3) Does it line up with the planning / future capabilities?
>> 4) Which of the above options (A, B, C) would you prefer?
>> 
>> -- 
>> Swen Boehm  | Email: bo...@ornl.gov
>> Oak Ridge National Laboratory  | Phone: +1 865-576-6125
>> 
>> 
>> On Apr 26, 2013, at 7:50 PM, Thomas Naughton  wrote:
>> 
>>> Hi,
>>> 
>>> Ok, sounds good. We'll check on this next week and get back to you.
>>> 
>>> Thanks,
>>> --tjn
>>> 
>>> _
>>> Thomas Naughton  naught...@ornl.gov
>>> Research Associate   (865) 576-4184
>>> 
>>> 
>>> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
>>> 
 Email would probably be easiest -- I will need to page in/refresh this 
 area of the code, anyway, so if you guys do the initial homework and 
 submit some ideas, that would probably be easiest (For me).  :-D
 
 
 On Apr 26, 2013, at 6:33 PM, Thomas Naughton 
 wrote:
 
> Hi Jeff,
> 
> We don't have one yet but we can code something up and submit a patch.
> 
> If useful we could quickly sync up beforehand to ensure we are on the 
> same page.   Phone or email, whatever would be easiest.
> 
> What do you think?
> --tjn
> 
> _
> Thomas Naughton  naught...@ornl.gov
> Research Associate   (865) 576-4184
> 
> 
> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
> 
>> I'm not aware of any plans to do this.
>> 
>> Do you guys have a patch to submit, perchance?  :-D
>> 
>> 
>> On Apr 22, 2013, at 6:30 PM, Thomas Naughton  wrote:
>> 
>>> Hi Nathan & Jeff,
>>> 
>>> You guys have done some MCA 

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Ralph Castain]

Crud - it just struck me that you don't want to do one thing in that patch.

> + Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
>  header file.


We use the frameworks.h file to "discover" the frameworks in ompi_info. Even if 
no components are built for that framework, there still are MCA params relating 
to the base of that framework. Sounds silly, I know - but there may be reasons 
to access those params - e.g., to set verbosity to verify that no components 
are being selected.

I think we need those frameworks to be listed...


On May 7, 2013, at 6:49 AM, Ralph Castain  wrote:

> 
> On May 7, 2013, at 6:19 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> On May 6, 2013, at 10:39 PM, Ralph Castain  wrote:
>> 
>>> Could someone help me out a bit here:
>>> 
>>> * I'm unaware of any mechanism for "ignoring" an entire framework. Was 
>>> something added for that purpose?
>> 
>> It's been in autogen.pl for a while -- check out the end of 
>> mca_process_framework() in autogen.pl.
> 
> I see - you didn't mean "ignore the framework", you meant "ignore all 
> components in this framework". The two are not the same thing. Ignoring the 
> framework would mean that we were somehow going to skip the base as well, 
> which couldn't possibly work. We've talked about that before and never could 
> figure out how to null-out all the framework level functions.
> 
>> 
>>> * What "non-MCA" projects are in our repository? Everything appears to be 
>>> based on MCA plugins.
>>> 
>>> * Looking at Trac, we eliminated all project/config directories when we did 
>>> the OMPI-RTE abstraction. So what are we looping across at the end of 
>>> autogen?
>> 
>> Yes, we did.  ORNL specifically asked me/Nathan off-list if they could add 
>> this loop in, because they have some off-trunk repos (e.g., STCI) that both 
>> still use the config/ directory stuff and have non-MCA projects.  I didn't 
>> see any harm in these things; e.g., the loop only adds -I if the directory 
>> exists.  I.e., I saw it as being an attempt to be friendly to those who are 
>> trying to use our lower laters (ORTE and/or OPAL) with non-OMPI projects.  I 
>> thought this fit in well with the move-the-BTLs-down-to-OPAL philosophy.
>> 
>> That being said, if others disagree -- e.g., Ralph has a valid point: this 
>> is to help projects that are outside of our trunk -- let's discuss.  This 
>> will probably be a useful topic to discuss today on the teleconf.
> 
> I don't object to it being there as it is a "no-op" for us - there was just 
> no explanation given as to why this was being done. So it looked like a patch 
> based on an old version of the trunk.
> 
> 
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 

Re: [OMPI devel] [OMPI bugs] [Open MPI] #3592: btl_openib: change SRQ defaults

[Joshua Ladd]

Reviewed by Mike D.

Josh

-Original Message-
From: bugs-boun...@open-mpi.org [mailto:bugs-boun...@open-mpi.org] On Behalf Of 
Open MPI
Sent: Thursday, May 02, 2013 9:10 AM
Cc: b...@open-mpi.org
Subject: [OMPI bugs] [Open MPI] #3592: btl_openib: change SRQ defaults

#3592: btl_openib: change SRQ defaults
---+
Reporter:  amikheev|  Owner:
Type:  changeset move request  | Status:  new
Priority:  major   |  Milestone:  Open MPI 1.7.2
 Version:  trunk   |   Keywords:
---+
 Apply r28440 and r28441 to 1.7 branch

-- 
Ticket URL: 
Open MPI 

___
bugs mailing list
b...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/bugs

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Thomas Naughton]

Hi,

Briefly, I'm Thomas.  I work at ORNL.  I changed autogen.pl on my
first commit to OMPI trunk. (Insert rookie joke here.  :-D)

The changes in r28456 for autogen.pl were pretty basic/minor.  I
apologize for not sending a follow-up email to devel mailing list
outlining the changes -- poor netiquette on my part. :-/

There were four changes included in the patch.  They related
mainly to the recent changes for MCA frameworks.  I'll give a little
more description below.

Ralph, I also included your feedback and a response for #2.  Let me
know if this makes sense as I think it provides the "right" behavior
but want to double check.  Thanks.



 1) Add ifdef guard to project's autogenerated "frameworks.h" header
file, e.g., "opal/inlude/opal/frameworks.h" would have
"OPAL_FRAMEWORKS_H".


This one simply adds and ifdef to top of auto-generated file, so if code
includes the "framework.h" file you avoid multiple includes of same file.
This is generic to the given project so the "opal/" project would generate
something like:

  $ cat opal/include/opal/frameworks.h
  /*
   * This file is autogenerated by autogen.pl. Do not edit this file by hand.
   */
  #ifndef OPAL_FRAMEWORKS_H
  #define OPAL_FRAMEWORKS_H

  #include 

  extern mca_base_framework_t opal_backtrace_base_framework;

 ..

  #endif /* OPAL_FRAMEWORKS_H */

This would also be done for "ompi/" and "orte/" project directories.





 2) Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
header file.


This simply applies the same ignored() function that is used elsewhere in
the autogen.pl script for omitting "ignored" MCA directories from the
processing.  This just picks up the ".ompi_ignore" (and/or ".ompi_unignore) 
files.   The intent being that if you ignore a component (subdir) that will

be removed from the list, but you could also remove an entire framework if
you put the ignore file in the top-level of the framework.

The intent being that if for whatever reason you ignore a framework in the
"${project}/mca/" space, you will not have it automatically show up in the
project's "frameworks.h" file.

On Tue, 7 May 2013, Ralph Castain wrote:


We use the frameworks.h file to "discover" the frameworks in
ompi_info.  Even if no components are built for that framework,
there still are MCA params relating to the base of that framework.
Sounds silly, I know - but there may be reasons to access those
params - e.g., to set verbosity to verify that no components are
being selected.

I think we need those frameworks to be listed...



Ok, I didn't realize the 'ompi_info' aspect.  Good to know.
However, I think honouring the ignore behavior is good in this case
b/c if you drop an ignore file in a framework, you won't get any
other autogen touches (i.e., no Makefile's are autogenerated).  So
it seems that having no Makefiles but including the framework in the
"framework.h" would break regardless.  Again, this is more of a
safety guard.





3) Avoid adding non-MCA projects to the autogenerated
'mca_project_list', which maintains existing support for "projects" 
with new MCA framework enhancements.  Moves this down to mca_run_global().



This was just a bit of shifting code and didn't sound like there was
any discussion on this point.  This is a "do no harm" factor to
support pre-existing functionality.  The gist is that if you have a
"project" in the build directory that doesn't have an MCA directory 
structure, just avoid adding it to the list of MCA projects.





4) Add small loop at end to add projects with a "config/" subdir
   to the list of includes for 'autoreconf'.



This again is a "do no harm" factor to support pre-exising
functionality.  If you have a "${project}/config/" directory.  This
appends  the "-I ${project}/config/" to the autoreconf list.
If you do not have a "${project}/config/" dir, there is no change.


Again, I hope that gives more context/description to the changes
included in the autogen.pl patch.  In the future, I'll try to do
a better job of sending a heads up to the devel list.

Thanks,
--tjn

 _
  Thomas Naughton  naught...@ornl.gov
  Research Associate   (865) 576-4184


On Tue, 7 May 2013, Ralph Castain wrote:


Crud - it just struck me that you don't want to do one thing in that patch.


+ Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
 header file.



We use the frameworks.h file to "discover" the frameworks in ompi_info. Even if 
no components are built for that framework, there still are MCA params relating to the 
base of that framework. Sounds silly, I know - but there may be reasons to access those 
params - e.g., to set verbosity to verify that no components are being selected.

I think we need those frameworks to be listed...


On May 7, 2013, at 6:49 AM, Ralph Castain  wrote:



On May 7, 2013, at 6:19 AM, Jeff Squy

Re: [OMPI devel] [OMPI bugs] [Open MPI] #3593: btl_openib: change SRQ defaults

[Joshua Ladd]

Please see below.

Josh

-Original Message-
From: bugs-boun...@open-mpi.org [mailto:bugs-boun...@open-mpi.org] On Behalf Of 
Open MPI
Sent: Thursday, May 02, 2013 9:12 AM
Cc: b...@open-mpi.org
Subject: [OMPI bugs] [Open MPI] #3593: btl_openib: change SRQ defaults

#3593: btl_openib: change SRQ defaults
-+
Reporter:  amikheev  |  Owner:
Type:  defect| Status:  new
Priority:  major |  Milestone:  Open MPI 1.6.5
 Version:  trunk |   Keywords:
-+
 Apply r28440 and r28441 to 1.6 branch

 reviewed by miked

-- 
Ticket URL: 
Open MPI 

___
bugs mailing list
b...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/bugs

Re: [OMPI devel] Q: project based MCA param files

[Thomas Naughton]

Hi,

Ok, looks like this may just do the trick.  We briefly discussed this today
and probably can change our use case to make use of this mechanism instead
and avoid any further enhancments.

 Question: If you do a setenv for this MCA param, does that extend the
   default search path?  Or does it replace/override the default?

Thanks Jeff for forwarding info to devel list to get broader feedback, and
to Ralph for providing the suggestion.

--tjn

 _
  Thomas Naughton  naught...@ornl.gov
  Research Associate   (865) 576-4184


On Tue, 7 May 2013, Ralph Castain wrote:


I believe we already have a way of defining where to get the default mca params:

   ret = mca_base_var_register ("opal", "mca", "base", "param_files", "Path for MCA 
"
"configuration files containing variable 
values",
MCA_BASE_VAR_TYPE_STRING, NULL, 0, 0, 
OPAL_INFO_LVL_2,
MCA_BASE_VAR_SCOPE_READONLY, 
&mca_base_var_files);


So wouldn't it be as easy as defining an envar? It's what we did when using the 
OMPI code with ORCM a couple of years ago, and we used it again for a recent 
project in Greenplum where the default mca param was specified in a different 
location than usual.


On May 7, 2013, at 6:28 AM, Jeff Squyres (jsquyres)  wrote:


Given Ralph's questions about 
rhttps://svn.open-mpi.org/trac/ompi/changeset/28456, ORNL's second question to 
me/Nathan about MCA params is probably worth forwarding to the list -- see 
below.

Thoughts on this proposal?


Begin forwarded message:


From: "Boehm, Swen" 
Subject: Re: Q: project based MCA param files
Date: May 3, 2013 5:03:43 PM EDT
To: "Jeff Squyres (jsquyres)" 
Cc: Nathan Hjelm , "Vallee, Geoffroy R." , "Naughton 
III, Thomas J." 

Hi Jeff,

Here is a short description of the enhancement we would like to contribute.
Let us know what you think.

The purpose of the suggested improvements is to enable "projects" to read
MCA parameters from project specific locations. This enables the usage
of OPAL and the MCA Frameworks outside the OpenMPI project without
interfering with OpenMPI specific parameters and removes the need to
patch OPAL (e.g., to pick up params from different locations).

The possible scenarios would be the following:

a) adding the option to pick up a project specific mca-param.conf file
 Example:
  $HOME/.mca/${project}-mca-param.conf
  and /etc/mca/${project}-mca-param.conf)

b) add the option to pick up the mca-param.conf file from a project specific
 directory
 Example:
  $HOME/.${project}/mca-param.conf
  and /etc/${project}/mca-param.conf
  and/or  /etc/${project}/${project}-mca-param.conf)

c) prefixing the mca param with the project name in the existing mca-param.conf
 file and therefore following the new MCA variable system naming scheme.
 Example:
  mca_${project}_${framework}_${component}_${var_name}

The implementation has to be compatible with the current system, that is,
it should work as it does today without any added burden to the user. The
suggested approach is to provide an addition to the MCA API (something like
mca_base_add_config_file_path ()) to add lookup paths to the MCA system.
This way additional files can be picked up for the MCA param parsing if
needed.

To wrap it up:
1) Is the motivation clear?
2) Is it possible to implement the desired capability within a
  reasonable time and without changing the current behavior?
3) Does it line up with the planning / future capabilities?
4) Which of the above options (A, B, C) would you prefer?

--
Swen Boehm  | Email: bo...@ornl.gov
Oak Ridge National Laboratory  | Phone: +1 865-576-6125


On Apr 26, 2013, at 7:50 PM, Thomas Naughton  wrote:


Hi,

Ok, sounds good. We'll check on this next week and get back to you.

Thanks,
--tjn

_
Thomas Naughton  naught...@ornl.gov
Research Associate   (865) 576-4184


On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:


Email would probably be easiest -- I will need to page in/refresh this area of 
the code, anyway, so if you guys do the initial homework and submit some ideas, 
that would probably be easiest (For me).  :-D


On Apr 26, 2013, at 6:33 PM, Thomas Naughton 
wrote:


Hi Jeff,

We don't have one yet but we can code something up and submit a patch.

If useful we could quickly sync up beforehand to ensure we are on the same 
page.   Phone or email, whatever would be easiest.

What do you think?
--tjn

_
Thomas Naughton  naught...@ornl.gov
Research Associate   (865) 576-4

Re: [OMPI devel] Q: project based MCA param files

[Jeff Squyres (jsquyres)]

On May 7, 2013, at 2:44 PM, Thomas Naughton  wrote:

> Ok, looks like this may just do the trick.  We briefly discussed this today
> and probably can change our use case to make use of this mechanism instead
> and avoid any further enhancments.
> 
> Question: If you do a setenv for this MCA param, does that extend the
>   default search path?  Or does it replace/override the default?

It replaces/overrides.

You don't have to do this via setenv-- you should be able to do it 
programatically, too.

> Thanks Jeff for forwarding info to devel list to get broader feedback, and
> to Ralph for providing the suggestion.
> 
> --tjn
> 
> _
>  Thomas Naughton  naught...@ornl.gov
>  Research Associate   (865) 576-4184
> 
> 
> On Tue, 7 May 2013, Ralph Castain wrote:
> 
>> I believe we already have a way of defining where to get the default mca 
>> params:
>> 
>>   ret = mca_base_var_register ("opal", "mca", "base", "param_files", "Path 
>> for MCA "
>>"configuration files containing variable 
>> values",
>>MCA_BASE_VAR_TYPE_STRING, NULL, 0, 0, 
>> OPAL_INFO_LVL_2,
>>MCA_BASE_VAR_SCOPE_READONLY, 
>> &mca_base_var_files);
>> 
>> 
>> So wouldn't it be as easy as defining an envar? It's what we did when using 
>> the OMPI code with ORCM a couple of years ago, and we used it again for a 
>> recent project in Greenplum where the default mca param was specified in a 
>> different location than usual.
>> 
>> 
>> On May 7, 2013, at 6:28 AM, Jeff Squyres (jsquyres)  
>> wrote:
>> 
>>> Given Ralph's questions about 
>>> rhttps://svn.open-mpi.org/trac/ompi/changeset/28456, ORNL's second question 
>>> to me/Nathan about MCA params is probably worth forwarding to the list -- 
>>> see below.
>>> 
>>> Thoughts on this proposal?
>>> 
>>> 
>>> Begin forwarded message:
>>> 
 From: "Boehm, Swen" 
 Subject: Re: Q: project based MCA param files
 Date: May 3, 2013 5:03:43 PM EDT
 To: "Jeff Squyres (jsquyres)" 
 Cc: Nathan Hjelm , "Vallee, Geoffroy R." 
 , "Naughton III, Thomas J." 
 
 Hi Jeff,
 
 Here is a short description of the enhancement we would like to contribute.
 Let us know what you think.
 
 The purpose of the suggested improvements is to enable "projects" to read
 MCA parameters from project specific locations. This enables the usage
 of OPAL and the MCA Frameworks outside the OpenMPI project without
 interfering with OpenMPI specific parameters and removes the need to
 patch OPAL (e.g., to pick up params from different locations).
 
 The possible scenarios would be the following:
 
 a) adding the option to pick up a project specific mca-param.conf file
 Example:
  $HOME/.mca/${project}-mca-param.conf
  and /etc/mca/${project}-mca-param.conf)
 
 b) add the option to pick up the mca-param.conf file from a project 
 specific
 directory
 Example:
  $HOME/.${project}/mca-param.conf
  and /etc/${project}/mca-param.conf
  and/or  /etc/${project}/${project}-mca-param.conf)
 
 c) prefixing the mca param with the project name in the existing 
 mca-param.conf
 file and therefore following the new MCA variable system naming scheme.
 Example:
  mca_${project}_${framework}_${component}_${var_name}
 
 The implementation has to be compatible with the current system, that is,
 it should work as it does today without any added burden to the user. The
 suggested approach is to provide an addition to the MCA API (something like
 mca_base_add_config_file_path ()) to add lookup paths to the MCA system.
 This way additional files can be picked up for the MCA param parsing if
 needed.
 
 To wrap it up:
 1) Is the motivation clear?
 2) Is it possible to implement the desired capability within a
  reasonable time and without changing the current behavior?
 3) Does it line up with the planning / future capabilities?
 4) Which of the above options (A, B, C) would you prefer?
 
 --
 Swen Boehm  | Email: bo...@ornl.gov
 Oak Ridge National Laboratory  | Phone: +1 865-576-6125
 
 
 On Apr 26, 2013, at 7:50 PM, Thomas Naughton  wrote:
 
> Hi,
> 
> Ok, sounds good. We'll check on this next week and get back to you.
> 
> Thanks,
> --tjn
> 
> _
> Thomas Naughton  naught...@ornl.gov
> Research Associate   (865) 576-4184
> 
> 
> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
> 
>> Email would probably be easiest -- I 

Re: [OMPI devel] June OMPI developer's meeting

[Larry Baker]

On 6 May 2013, at 11:14 AM, Jeff Squyres (jsquyres) wrote:

> We typically do something informally scheduled on the day of, or somesuch 
> (e.g., around 4pm people start wondering aloud what we should do for dinner 
> :-) ).  But if there is interest for others to attend, we can probably set up 
> something ahead of time.


This option will work best for me.  All I need is an e-mail notice of where and 
when within 30 minutes or so of the reservation time (depending on the traffic 
on 101 :) ).

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Ralph Castain]

On May 7, 2013, at 11:34 AM, Thomas Naughton  wrote:

> Hi,
> 
> Briefly, I'm Thomas.  I work at ORNL.  I changed autogen.pl on my
> first commit to OMPI trunk. (Insert rookie joke here.  :-D)

Welcome!

> 
> The changes in r28456 for autogen.pl were pretty basic/minor.  I
> apologize for not sending a follow-up email to devel mailing list
> outlining the changes -- poor netiquette on my part. :-/
> 
> There were four changes included in the patch.  They related
> mainly to the recent changes for MCA frameworks.  I'll give a little
> more description below.
> 
> Ralph, I also included your feedback and a response for #2.  Let me
> know if this makes sense as I think it provides the "right" behavior
> but want to double check.  Thanks.
> 
> 
>> 1) Add ifdef guard to project's autogenerated "frameworks.h" header
>>file, e.g., "opal/inlude/opal/frameworks.h" would have
>>"OPAL_FRAMEWORKS_H".
> 
> This one simply adds and ifdef to top of auto-generated file, so if code
> includes the "framework.h" file you avoid multiple includes of same file.
> This is generic to the given project so the "opal/" project would generate
> something like:
> 
>  $ cat opal/include/opal/frameworks.h
>  /*
>   * This file is autogenerated by autogen.pl. Do not edit this file by hand.
>   */
>  #ifndef OPAL_FRAMEWORKS_H
>  #define OPAL_FRAMEWORKS_H
> 
>  #include 
> 
>  extern mca_base_framework_t opal_backtrace_base_framework;
> 
> ..
> 
>  #endif /* OPAL_FRAMEWORKS_H */
> 
> This would also be done for "ompi/" and "orte/" project directories.
> 

No issues from anyone that I heard.

> 
> 
> 
>> 2) Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
>>header file.
> 
> This simply applies the same ignored() function that is used elsewhere in
> the autogen.pl script for omitting "ignored" MCA directories from the
> processing.  This just picks up the ".ompi_ignore" (and/or ".ompi_unignore) 
> files.   The intent being that if you ignore a component (subdir) that will
> be removed from the list, but you could also remove an entire framework if
> you put the ignore file in the top-level of the framework.

That is new - I would suggest not doing that as it behaves differently than you 
might expect. The .ompi_ignore in a component prevents that component from 
building at all, so it won't ever be opened etc. However, the framework *must* 
build the base code no matter what - and that means the framework will be 
opened, selected, and closed at the minimum.

I would prefer we keep ompi_ignore cleanly defined. You can ignore all 
components by simply putting --enable-mca-no-build= on your 
configure line.

> 
> The intent being that if for whatever reason you ignore a framework in the
> "${project}/mca/" space, you will not have it automatically show up in the
> project's "frameworks.h" file.
> 
> On Tue, 7 May 2013, Ralph Castain wrote:
> 
>>> We use the frameworks.h file to "discover" the frameworks in
>>> ompi_info.  Even if no components are built for that framework,
>>> there still are MCA params relating to the base of that framework.
>>> Sounds silly, I know - but there may be reasons to access those
>>> params - e.g., to set verbosity to verify that no components are
>>> being selected.
>>> 
>>> I think we need those frameworks to be listed...
> 
> 
> Ok, I didn't realize the 'ompi_info' aspect.  Good to know.
> However, I think honouring the ignore behavior is good in this case
> b/c if you drop an ignore file in a framework, you won't get any
> other autogen touches (i.e., no Makefile's are autogenerated).  So
> it seems that having no Makefiles but including the framework in the
> "framework.h" would break regardless.  Again, this is more of a
> safety guard.
> 
> 

Actually, I disagree. As stated above, the framework will *always* build the 
base code and be opened, selected, and closed - so you at least need access to 
the verbosity parameter so you can verify those operations. Keeping it in 
ompi_info is of value.

> 
> 
>> 3) Avoid adding non-MCA projects to the autogenerated
>> 'mca_project_list', which maintains existing support for "projects" with new 
>> MCA framework enhancements.  Moves this down to mca_run_global().
> 
> 
> This was just a bit of shifting code and didn't sound like there was
> any discussion on this point.  This is a "do no harm" factor to
> support pre-existing functionality.  The gist is that if you have a
> "project" in the build directory that doesn't have an MCA directory 
> structure, just avoid adding it to the list of MCA projects.

No objections

> 
> 
> 
>> 4) Add small loop at end to add projects with a "config/" subdir
>>   to the list of includes for 'autoreconf'.
> 
> 
> This again is a "do no harm" factor to support pre-exising
> functionality.  If you have a "${project}/config/" directory.  This
> appends  the "-I ${project}/config/" to the autoreconf list.
> If you do not have a "${project}/config/" dir, there is no change.
> 

No objections -