As fond as I am of the AMBER_NTHREADS idea, for the purpose of testing I think having several sets is perfectly acceptable. It just needs to be documented.
Another question: is there a preferred numprocs range for tests? That way, the docs can say something like "most parallel tests can be run using anywhere between 2 and 32 threads, but a few (see instructions below) have special requirements."
:-) Lachele
--
B. Lachele Foley, PhD '92,'02
Assistant Research Scientist
Complex Carbohydrate Research Center, UGA
706-542-0263
lfoley.ccrc.uga.edu
----- Original Message -----
From: Jason Swails
[mailto:jason.swails.gmail.com]
To: AMBER Developers Mailing List
[mailto:amber-developers.ambermd.org]
Sent: Thu, 18 Feb 2010 16:29:55
-0500
Subject: Re: [AMBER-Developers] incompatible processor requirements in
parallel tests
> On Thu, Feb 18, 2010 at 4:13 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> > Hi All,
> >
> > Just to throw a spanner in the works here, you cannot assume that the
> number
> > of threads can be specified on the mpirun / mpiexec command line. Often it
> > is an environment variable or a setting set by the queuing system that the
> > user cannot override. For example IBM Power systems use :
>
> I know this to be true for a large number of queuing systems in HPC
> environments. For example, with mpich2/derivatives, you can pass
> mpdboot a machinefile (i think), and mpiexec needs no processor count
> associated with it. In this case, $AMBER_NTHREADS would be unused.
> To this end, the new 4proc, 8proc, and 32proc test rules would still
> serve their purpose.
>
> However, if I'm understanding numprocs.awk correctly (I don't know awk
> that well, but I'm familiar with some C-type syntax, and it looks like
> a very simple script), it will grab the number of processors from the
> argument following -np or -n (perhaps -c should be tossed in there as
> well), so wouldn't this, also, be useless in the situations described
> above?
>
> However, if any of the tests are being done interactively, I'd imagine
> that -np or -n (or something of the like) would have to be specified
> (because how else would the MPI know how many threads to start?). The
> main reason I can think of for not implementing this would be that the
> gains would not be worth the effort required to implement the change.
>
> All the best,
> Jason
>
> --
> ---------------------------------------
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 18 2010 - 14:30:03 PST