Committed in r1222.
If you want a directory in ompi-tests/ to save your ornl scripts and
ini files (perhaps analogous to ompi-tests/cisco and ompi-tests/iu),
let us know.
On Aug 20, 2008, at 10:38 AM, Matney Sr, Kenneth D. wrote:
Hi Jeff,
The trunk needs an additional patch to make ALPS work (without
complaints). I have attached it hereto. Also, I will send along the
ornl.ini script when I get it finalized. This wlll show how we do
Cray
XT builds, run, etc.
--
Ken
-----Original Message-----
From: mtt-users-boun...@open-mpi.org
[mailto:mtt-users-boun...@open-mpi.org] On Behalf Of Jeff Squyres
Sent: Thursday, August 14, 2008 10:47 AM
To: General user list for the MPI Testing Tool
Subject: Re: [MTT users] FW: ALPS modifications for MTT
BTW, I committed this patch to the MTT trunk.
I feel a little sheepish; I should have told you to use the trunk
these days, not the release branch (I know the wiki specifically says
otherwise). We really need to finally make a release out of what is
on the trunk -- it's much more advanced than what is on the release
branch (look at the CHANGES file in the top-level dir to see what has
changed since the release branch).
The Cisco MTT files in SVN are for the trunk; it's possible that the
features that the release branch doesn't understand will just be
ignored, but I haven't tried this in a long time.
On Aug 14, 2008, at 10:35 AM, Jeff Squyres wrote:
This patch looks good to me.
I'll commit. If you want to do any more work on MTT, perhaps ORNL
can add you to its "Schedule A" form for the Open MPI Third Party
Contribution form (it's very easy to amend Schedule A -- doesn't
require any authoritative signatures), we could get you an MTT SVN
account and you could commit this stuff directly.
On Aug 14, 2008, at 10:24 AM, Matney Sr, Kenneth D. wrote:
Hi,
When running MTT on the Cray XT3/XT4 machines, I found that MTT
does not
contain any support for ALPS. As a result, it always executes
mpirun
with "-np 1". I patched lib/MTT/Values/Functions.pm with the
following
to overcome this:
-----Original Message-----
From: Matney Sr, Kenneth D.
Sent: Wednesday, August 13, 2008 5:57 PM
To: Shipman, Galen M.
Cc: Graham, Richard L.
Subject: FW: ALPS modifications for MTT
--- Functions-bak.pm 2008-08-06 14:31:26.256538000 -0400
+++ Functions.pm 2008-08-13 17:43:40.273641000 -0400
@@ -602,6 +602,8 @@
# Resource managers
return "SLURM"
if slurm_job();
+ return "ALPS"
+ if alps_job();
return "TM"
if pbs_job();
return "N1GE"
@@ -638,6 +640,8 @@
# Resource managers
return slurm_max_procs()
if slurm_job();
+ return alps_max_procs()
+ if alps_job();
return pbs_max_procs()
if pbs_job();
return n1ge_max_procs()
@@ -670,6 +674,8 @@
# Resource managers
return slurm_hosts()
if slurm_job();
+ return alps_hosts()
+ if alps_job();
return pbs_hosts()
if pbs_job();
return n1ge_hosts()
@@ -1004,6 +1010,70 @@
#-----------------------------------------------------------------------
---
+# Return "1" if we're running in an ALPS job; "0" otherwise.
+sub alps_job {
+ Debug("&alps_job\n");
+
+# It is true that ALPS can be run in an interactive access mode;
however,
+# this would not be a true managed environment. Such only can be
+# achieved under a batch scheduler.
+ return ((exists($ENV{BATCH_PARTITION_ID}) &&
+ exists($ENV{PBS_NNODES})) ? "1" : "0");
+}
+
+
#----------------------------------------------------------------------
----
+
+# If in an ALPS job, return the max number of processes we can run.
+# Otherwise, return 0.
+sub alps_max_procs {
+ Debug("&alps_max_procs\n");
+
+ return "0"
+ if (!alps_job());
+
+# If we were not running under PBS or some other batch system, we
would
+# not have the foggiest idea of how many processes mpirun could
spawn.
+ my $ret;
+ $ret=$ENV{PBS_NNODES};
+
+ Debug("&alps_max_procs returning: $ret\n");
+ return "$ret";
+}
+
+
#----------------------------------------------------------------------
----
+
+# If in an ALPS job, return the hosts we can run on. Otherwise,
return
+# "".
+sub alps_hosts {
+ Debug("&alps_hosts\n");
+
+ return ""
+ if (!alps_job());
+
+# Again, we need a batch system to achieve management; return the
uniq'ed
+# contents of $PBS_HOSTFILE. Actually, on the Cray XT, we can
return
the
+# NIDS allocated by ALPS; but, without launching servers to other
service
+# nodes, all communication is via the launching node and NIDS
actually
+# have no persistent resource allocated to the user. That is,
all
file
+# resources accessible from a NID are shared with the launching
node.
+# And, since ALPS is managed by the batch system, only the
launching
node
+# can initiate communication with a NID. In effect, the Cray XT
model is
+# of a single service node with a varying number of compute
processors.
+ open (FILE, $ENV{PBS_NODEFILE}) || return "";
+ my $lines;
+ while (<FILE>) {
+ chomp;
+ $lines->{$_} = 1;
+ }
+
+ my @hosts = sort(keys(%$lines));
+ my $hosts = join(",", @hosts);
+ Debug("&alps_hosts returning: $hosts\n");
+ return "$hosts";
+}
+
+
#----------------------------------------------------------------------
----
+
# Return "1" if we're running in a PBS job; "0" otherwise.
sub pbs_job {
Debug("&pbs_job\n");
--
Ken
_______________________________________________
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
--
Jeff Squyres
Cisco Systems
_______________________________________________
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
--
Jeff Squyres
Cisco Systems
_______________________________________________
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
<kmymtt2.patch>_______________________________________________
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
--
Jeff Squyres
Cisco Systems
