Okay, it took me awhile to grok thru all this, and I now understand how it is
working. You do have a question, though, with duplicated entries. At the
moment, we ignore any entry that is duplicated on the configure cmd line -
i.e., if you set something in a platform file, and then attempt to als
I keep scratching my head over this, and I just cannot figure out how this is
going to do what you think. We "source" the platform file solely to execute any
envar settings that are in it - i.e., to capture the CFLAGS=... and other such
directives. We then read/parse the platform file to get all
This is what was missing from your RFC - a simple explanation other than a
one-line "How" or "Why". I know it takes five minutes to be more descriptive,
but you've been getting awfully terse lately with these proposals.
Now that you have explained it, I have no objections.
On Jul 9, 2012, at 3
On Mon, Jul 09, 2012 at 03:31:33PM -0700, Ralph Castain wrote:
> So if I understand this right, you would have multiple platform files, each
> "sourcing" a common one that contains the base directives? It sounds to me
> like you need more than the change below to make that work - you would need
So if I understand this right, you would have multiple platform files, each
"sourcing" a common one that contains the base directives? It sounds to me like
you need more than the change below to make that work - you would need to
interpret the platform file itself to read and execute a "source"
LANL's platform file's (for a particular platform) are 90% the same. By
allowing a source directive those settings can be kept in a common file then
sourced by the platform file. When something changes I wouldn't have to change
a dozen files only a couple.
-Nathan
On Mon, Jul 09, 2012 at 02:21
I'm confused - how does this help maintain a platform file???
On Jul 9, 2012, at 2:09 PM, Nathan Hjelm wrote:
> When: Thurs, Jul 12, 5 PM MDT
>
> Why: Useful feature. Enabling source may cut down on the maintenance required
> to keep platform files up to date.
>
> How: Change directories to t
Ok, some basic non-blocking tests should be in now, including mpif.h, use mpi,
and use mpi_f08 versions -- see r26768 in ompi-tests.
They're not great tests -- it would be wonderful if someone would write some
better ones. :-) But they at least verify basic functionality.
(and they did find t
When: Thurs, Jul 12, 5 PM MDT
Why: Useful feature. Enabling source may cut down on the maintenance required
to keep platform files up to date.
How: Change directories to the platform file's directory before sourcing it
(not after).
diff --git a/config/ompi_load_platform.m4 b/config/ompi_load_p
We had just recently bumped up the Autotools triple used to create the trunk
and v1.7 tarballs to include Automake 1.12.1. Due to the notice below, I have
bumped it up to 1.12.2. Nightly tarballs starting tonight will use this new
version.
I have also patched the Automake that is being used t
I am playing with the Open MPI wrappers and had a couple of questions:
- If an argument is used to select a section (compiler_args) is that option
supposed to be passed to the compiler (because it is)?
- If the above is the intended behavior is there any objection to an
additional wrapper optio
I am running into similar issues with both Mellanox and IBM HCAs.
On a node installed with RHEL6.2 and MLNX_OFED-1.5.3-3.0.0, there is a
significant hit to locked memory when going with the device's max_cqe.
Here, for comparison's sake is the memory utilization for a simple MPI
process when using
Ah, not quite.
All those non-blocking collective tests (including the Fortran) weren't quite
finished because I wrote them because libnbc hadn't been slurped in yet.
Thanks for reminding me -- I'll go finish them now...
On Jul 6, 2012, at 6:35 PM, Eugene Loh wrote:
> I assume this is an orpha
13 matches
Mail list logo
