Subject: Re: [MTT users] [OMPI users] Request access to ompi-tests directory into svn
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-01-05 16:59:09


On Jan 5, 2012, at 4:46 PM, Юлов Дмитрий wrote:

> Yes, but a little. Unfortunately I don't see description of the
> structure tree of tests. :(

I'm not sure what you're asking here -- the tree structure doesn't matter...?

We have a particular tree structure in the ompi-tests SVN repository, of course, but MTT doesn't depend on that (or any other) specific tree structure.

Let me give you an example -- the IBM MPI test suite from the ARM .ini file example I sent earlier:

-----
[Test get: ibm]
module = SCM
scm_module = SVN
scm_url = https://svn.open-mpi.org/svn/ompi-tests/trunk/ibm
scm_post_copy = <<EOT
./autogen.sh
EOT
-----

This just does a check out of the IBM MPI test suite. It's multiple directories. After it does the checkout, it runs "autogen.sh" in the top-level directory of the checkout (which runs the GNU autotools, like autoconf, automake, ...etc.).

Then we build the IBM MPI test suite with:

-----
[Test build: ibm]
test_get = ibm
save_stdout_on_success = 1
merge_stdout_stderr = 1

module = Shell
shell_build_command = <<EOT
./configure
make
EOT
-----

The "Shell" module allows you to specify simply shell commands. In this case, it's a simple "./configure" followed by "make".

The test run is a bit more complicated, because we have several kinds of tests
in the IBM MPI test suite:

-----
[Test run: ibm]
include_section = Defaults Test run

test_build = ibm
timeout = &max(30, &multiply(10, &test_np()))

specify_module = Simple
simple_first:np = &env_max_procs()
simple_first:tests = &find_executables("collective", "communicator", \
                                       "datatype", "dynamic", "environment", \
                                       "group", "info", "io", "onesided", \
                                       "pt2pt", "random", "topology")
-----

Let's look at this part ^^ so far.

The "Simple" specify module specifies which executes to run. We use the &find_executables() funclet to find all executables in the directories listed (collective/, communicator/, ...etc.). This is a simpler way of identifying which tests to run rather than listing them all in the .ini file.

You could also do &find_executables("."), which would search the whole tree. But that would find things like "configure" and "libtool", and the like. So in this case, we listed all the subdirectories that contain the built MPI tests.

Continuing on...

-----
# Tests that are supposed to fail
simple_fail:tests = environment/abort environment/final
simple_fail:pass = &and(&test_wifexited(), &ne(&test_wexitstatus(), 0))
simple_fail:exclusive = 1
simple_fail:timeout = &env_max_procs()
-----

You can put an arbitrary tag before a colon (:) and then list keywords like tests, pass, np, exclusive, timeout, etc. This creates a subset of tests.

In this case, we have 2 tests that are *supposed* to fail (i.e., they call MPI_Abort), and therefore the "pass" criteria for these two tests needs to be different than the rest. The executables environment/abort and environment/final are the two tests in question.

We specify a different "pass" criteria here. The "exclusive" field means that this subset of tests should not be run in any other subsets (i.e., the main set of tests that were found by &find_executables(), above.

Continuing on...

-----
# Spawn tests; need to run very few
simple_spawns:tests = dynamic/spawn dynamic/spawn_multiple
simple_spawns:np = 3
simple_spawns:pass = &and(&test_wifexited(), &eq(&test_wexitstatus(),0))
simple_spawns:exclusive = 1
simple_spawns:timeout = &multiply(5,&env_max_procs())
-----

This subset needed an override on the np value and the timeout.

-----
# Big loop o' spawns
loop_spawn:tests = dynamic/loop_spawn
loop_spawn:np = 1
loop_spawn:pass = &and(&test_wifexited(), &eq(&test_wexitstatus(),0))
loop_spawn:exclusive = 1
loop_spawn:timeout = 600
-----

Again, override the np and timeout values for this subset.

-----
# THREAD_MULTIPLE test will fail with the openib btl because it
# deactivates itself in the presence of THREAD_MULTIPLE. So just skip
# it. loop_child is the target for loop_spawn, so we don't need to
# run it (although it'll safely pass if you run it by itself).
simple_skip:tests = environment/init_thread_multiple dynamic/loop_child
simple_skip:exclusive = 1
simple_skip:do_not_run = 1
-----

I am explicitly skipping these tests (do_not_run), mainly out of laziness. :-)

Does this help?

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/