On Thu, Feb 18, 2010 at 10:37 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
>> (1) it is probably not very practical to run tests using queuing
>> systems
>> anyway
>
> Except that on a LOT of systems these days this is the only way to run the
> test cases since interactive parallel jobs are not allowed or are limited to
> a short amount of time that is not sufficient to get the tests completed. On
> some, but not all, systems one can request an interactive job through the
> queuing system and conceivably run the tests this way but of course the same
> issues surround what the 'mpirun' command looks like.
Yes, but on, for example, the Cray (kraken), numprocs still pulls the
right number of threads as aprun -n total -N pernode, and that's not
really a problem. $AMBER_NTHREADS can be used there. There has to be
some way on any system to specify the total number of processors to
whatever the user wants...
>> (3) I am basically suggested a possibility to put a "tag" (named
>> in some unique way; for example AMBER_NTHREADS) everywhere it
>> is needed in the DO_PARALLEL
>> command, and then replace it with the desired number;
>> i.e., instead of export DO_PARALLEL='mpirun -np 4' user would do
>> export DO_PARALLEL='mpirun -np AMBER_NTHREADS'; I don't know
>> whether
>> it is worth the effort, probably not since this is just slightly
>> less typing over (2), which is much less intrusive
>
> This is the bit I do not think will work and I do not think can be made
> anywhere near general enough. Note a number of systems, for example CRAY,
> specify both the size of the job (in cores) and the number of cores per node
> to use. Would it not make more sense to have several parallel test targets.
DO_PARALLEL="aprun -n $AMBER_NTHREADS -N $AMBER_NTHREADS" will work
just fine, and a user can request a single node and run up to 12
threads on separate cores. Only one job requires more (32) threads.
>
> E.g. (better names are probably possible)
>
> test.parallel
> Tests that can run on any number of cpus.
*any* number of CPUs is rather cumbersome here. Many are very
flexible, but will not go over 4, or perhaps 5 or 6 (however many
residues the system happens to have), etc. The way it's set up, users
can be told to run test.parallel with 2 procs, then run
test.parallel.4proc appropriately set for 4 processors,
test.parallel.8proc appropriately set for 8 processors, etc. The jobs
that aren't run with only 2 processors in test.parallel don't matter
too much, since people are told to run the other rules as well, so
those cases will be gone back to. It also does not preclude running
test.parallel with any number of processors (or the 4proc with 8,
etc.).
Appropriately documented, I think the current implementation is
probably sufficient (and the best part about it is that it took the
better part of 2 minutes to do it). However, what you describe is
probably much better, but finding someone to put in the leg work to
organize these tests this way may be hard.
All the best,
Jason
>
> test.2cpu
> Tests that only run on 2 cpus.
>
> test.4cpu
> Tests that only run on 4 cpus.
>
> etc. Of course this doesn't deal with the fact that a lot of the test cases
> will run on up to 4 cpus say and that is all but happily run on 1,2,3 or 4
> cpus. The current approach that some test cases have, which is to skip the
> test if the number of cpus is not compatible is a bad idea I think since
> this just results in these test cases never being run.
---------------------------------------
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 18 2010 - 20:30:02 PST
