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
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
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
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
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
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
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
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
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"
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
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
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
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
13 matches
Mail list logo