Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.4.3a1r4608
Start time: Mon Jul 9 21:04:38 EDT 2012
End time: Mon Jul 9 21:07:36 EDT 2012
Your friendly daemon,
Cyrador
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
