FWIW, I think that we will be treating these scenarios as the same
thing (i.e., running MTT against a developer build will be the same
thing as running MTT against an already-installed OMPI.
At least, that's the intent right now. We'll see what happens when
we start implementing... :-)
On Feb 26, 2007, at 1:14 PM, Yiftah Shahar wrote:
> Hi Jeff,
> Unfortunately we currently do not work with MTT but we are going to
> this soon.
> Your suggestions will defiantly make it easy/simple to use MTT and
> probably also test the MPI as it is being used in customer's
> (like with low register memory consumption, no "special" feature
> leave-pin ...).
> One more feature that we are looking for MTT is the ability to test
> cluster where we already install Open MPI (skip the mpi installation
> stage and point the test compilation/running to the directory we
> want to
>> -----Original Message-----
>> From: devel-core-bounces_at_[hidden] [mailto:devel-core-
>> mpi.org] On Behalf Of Jeff Squyres
>> Sent: Saturday, February 24, 2007 04:33
>> To: Open MPI Core Developers
>> Cc: MPI Testing Tool Users
>> Subject: [devel-core] Running MTT in developers' SVN checkouts
>> At the UTK meeting, a few organizations indicated to me that being
>> able to run MTT over a developer's tree is getting to be a higher
>> priority. So I'd like to ask the developer community exactly what
>> you want.
>> MTT is a highly flexible system with lots of available options. I'm
>> *guessing* that developers don't really want all that flexibility --
>> you just want to run a simple thingy against your development tree
>> and get a simple text report at the end indicating "passed" or
>> However, at least *some* flexibility is going to be required -- every
>> developer will need to run the tests a different way (different MCA
>> parameters, different number of processes, different set of
>> tests, ...etc.).
>> It would be most helpful to Ethan and me if the developers could send
>> us their thoughts on what you want out of MTT to be able to run
>> against your local development trees. Here are some suggestions:
>> 1. A list of desired use-case scenarios (the more detailed, the
>> 2. A list of desired outputs (the more detailed -- to include sample
>> outputs you'd like to see -- the better)
>> 3. How the flexibility should be effected (command line? text config
>> file? ...?)
>> 4. Suggested [default] list of tests to run (trivial? and/or intel?
>> and/or ibm? and/or ...?)
>> 5. Anything else you can think of.
>> Jeff Squyres
>> Server Virtualization Business Unit
>> Cisco Systems
>> devel-core mailing list
> devel-core mailing list
Server Virtualization Business Unit