[OMPI devel] Failed datatype test

2009-09-03 Thread Ralph Castain

Hi folks

A recent commit to the trunk is apparently causing "make check" to  
fail due to an assertion failure in an opal datatype test. I have  
turned this test "off" until someone can fix it as it is preventing  
the creation of a tarball.


Could someone knowledgeable in the datatype changes over the last few  
weeks/months please fix this?


Thanks
Ralph



[OMPI devel] suffix flag problems

2009-09-03 Thread David Robertson

Hi all,

We use both the PGI and Intel compilers over an Infiniband cluster and I 
was trying to find a way to have both orteruns in the path (in separate 
directories) at the same time. I decided to use the --program-suffix 
option. However, all the symlinks in the resulting bin directory point 
to executables without the suffix. i.e. mpirun points to orterun when it 
should point to orterun-pgi. I don't know if the suffixes need to be 
added in other places as well.


For now I have manually replaced the symlinks.

Thanks,
Dave



Re: [OMPI devel] RFC - "system-wide-only" MCA parameters

2009-09-03 Thread Graham, Richard L.
What happens if $sysconfdir/openmpi-priv-mca-params.conf is missing ?

Can the file name ( openmpi-priv-mca-params.conf ) also be configurable ?

Rich


On 9/3/09 5:23 AM, "Nadia Derbey"  wrote:



What: Define a way for the system administrator to prevent users from
  overwriting the default system-wide MCA parameters settings.

Why: Letting the user completely free of changing any MCA parameter
 that has been defined on a system-wide basis may sometimes be
 undesirable.

Where: code can be found at
http://derb...@bitbucket.org/derbeyn/opal-ro-mca-params/

---

Description:


Letting the user completely free of changing any parameter that has been
defined on a system-wide basis may sometimes be undesirable. For
example, on a node with multiple TCP interfaces, the system
administrator may for some reason want to restrict MPI applications to a
fixed subset of these TCP interfaces.

Today, there is no way for the system administrator to prevent users
from overwriting the default system-wide settings: even if he has
excluded eth0 from the interfaces usable by an MPI application, he
cannot prevent any user from explicitly using that excluded interface.

The purpose of this feature is to provide a new "system-wide-only"
property for the MCA parameters, specifying that their system-wide
value, if it has been defined, can never be overridden. This implies
changing the existing parameters setting rules.


Implementation:

It should be noted that this feature is already described in
https://svn.open-mpi.org/trac/ompi/ticket/75 as follows:
"another MCA parameter file that has "privileged" MCA parameters. This
file is hard-coded in the code base (based on $prefix, likely
"$sysconfdir/openmpi-priv-mca-params.conf", or somesuch). Any parameters
set in this file will be treated specially and cannot be overridden."

But we chose another way to implement this feature: the file
$sysconfdir/openmpi-mca-params.conf is kept with all the parameters
settings (even those that are considered as system-wide-only).
And the new file $sysconfdir/openmpi-priv-mca-params.conf is introduced
to contain only the list of the "privileged" parameters (not their value).
Doing it that way makes it easier to change the status of the MCA
parameters: moving them from privileged to non privileged is only a
matter of removing the new file, which preserves compatibility.
While with the solution proposed in the ticket, we have to merge both files.

The configuration files are parsed in the following order:
1. $sysconfdir/openmpi-mca-params.conf.
2. $sysconfdir/openmpi-priv-mca-params.conf
3. $HOME/.openmpi/mca-param.conf

When openmpi-priv-mca-params.conf is parsed, any parameter listed in
that file is moved from the mca_base_param_file_values list to a new
parallel list (mca_base_priv_param_file_values). The parameter remains
"hidden" in that new list.
The lookup order has been changed: the new
mca_base_priv_param_file_values list is the very 1st one to be scanned:
this is how we ensure that the "privileged" parameters are never
overwritten once defined on a system-wide basis.

Other external changes:
1. The man page for mpirun(1) has been changed.
2. The ompi_info(1) output has been changed to reflect the status of
these "privileged" parameters. The status field can now be one of
"read-only", "writable" or "privileged".
3. A new option has been added to ompi_info(1): --privileged
it outputs only the list of parameters that have been defined as
system-wide-only.


TODO list:
. Make this feature configurable.
. Output a warning message as described in the ticket.


Possible extension to this functionality:

This new functionality can be extended in the future in the following
way: allow the administrator to specify boundaries within which an MCA
parameter is allowed to be changed by a higher priority setting. This
means that the administrator should declare min and max values (or even
a set of discrete values) for any such parameter. Then, any higher
priority setting will be done only if the new value belongs to the
declared set.
In other word, each MCA parameter can be
   1. set to a given value in openmpi-mca-params.conf
   2. declared in openmpi-priv-mca-params.conf with its allowed boundaries
Then, if the user calls mpirun with that MCA parameter set in his
private mca-params.conf file, or in an AMCA file, or in an environment
variable, or on the command line, the new value will override the
system-wide value only if it is within the declared boundaries.

This could be thought of as a future development.

--
Nadia Derbey 



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




Re: [OMPI devel] suffix flag problems

2009-09-03 Thread Chris Samuel

- "David Robertson"  wrote:

> Hi all,

Hiya,

> We use both the PGI and Intel compilers over an
> Infiniband cluster and I was trying to find a way
> to have both orteruns in the path (in separate
> directories) at the same time.

Not a solution, but what we do here is to arrange our
installs into separate locations thus:

/usr/local/openmpi-gcc/$version
/usr/local/openmpi-intel/$version
/usr/local/openmpi-pgi/$version

and then use Modules (modules.sf.net) to let users easily
select which they want to use, so to load the default OMPI
for the Intel compilers they do:

module load openmpi-intel

We use symlinks for the module files to a generic one which
uses some lrange and split in tcl to derive the application
and compiler from the name of the module and loads the
compiler module if it's not already been loaded.

Users load a "vpac" module from their profile/cshrc at
login time and that pulls in our suggested defaults for
that cluster.

Makes life a lot easier for our users (and us!).

cheers,
Chris
-- 
Christopher Samuel - (03) 9925 4751 - Systems Manager
 The Victorian Partnership for Advanced Computing
 P.O. Box 201, Carlton South, VIC 3053, Australia
VPAC is a not-for-profit Registered Research Agency


Re: [OMPI devel] Failed datatype test

2009-09-03 Thread Jeff Squyres
FWIW, I get a bunch of valid-looking compiler warnings when running  
"make check" in the test/datatype directory.


On Sep 3, 2009, at 7:42 PM, Ralph Castain wrote:


Hi folks

A recent commit to the trunk is apparently causing "make check" to
fail due to an assertion failure in an opal datatype test. I have
turned this test "off" until someone can fix it as it is preventing
the creation of a tarball.

Could someone knowledgeable in the datatype changes over the last few
weeks/months please fix this?

Thanks
Ralph

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




--
Jeff Squyres
jsquy...@cisco.com