Hi,
There are several ways to implement my suggestion.
The best way probably will depend on the outcome of the thread:
Subject: RE: [AMBER-Developers] incompatible processor requirements in tests
The simplest way is probably to just have a separate test script for
1 through x-1 procs, where x is the required number for nonfailure.
I'll follow up on this.
Scott
On Sun, Feb 21, 2010 at 10:12:08AM -0500, Carlos Simmerling wrote:
> not sure- it sounded like Scott suggested a script that ran through multiple
> thread counts, generating output for each and diffing them against saves.
> not difficult, but probably best to standardize all of the tests the same
> way.
>
>
> On Sun, Feb 21, 2010 at 9:45 AM, Jason Swails <jason.swails.gmail.com>wrote:
>
> > $AMBERHOME/test/rem_gb_4rep has a script that tests for the number of
> > processors... Is this the type of thing you're looking for?
> >
> > On Sun, Feb 21, 2010 at 9:19 AM, Carlos Simmerling
> > <carlos.simmerling.gmail.com> wrote:
> > > Scott, can you point me to something like a template for a test case that
> > > does this, so I can set up something similar?
> > > carlos
> > >
> > > On Fri, Feb 19, 2010 at 2:57 AM, Scott Brozell <sbrozell.rci.rutgers.edu
> > >wrote:
> > >
> > >> Hi,
> > >>
> > >> Now is a good time to reiterate that features requiring x parallel
> > >> processors should have tests for 1 through x numbers of processors.
> > >> These tests serve several purposes, notably:
> > >> validating that the feature fails gracefully,
> > >> and documenting the parallel requirements of the feature.
> > >>
> > >> Writers going the extra mile could have these test cases emit terse
> > >> messages reminding users of the feature to run tests with at least x
> > >> parallel processors.
> > >>
> > >> thanks to everyone that contributed to the thread:
> > >> Subject: RE: [AMBER-Developers] incompatible processor requirements in
> > >> parallel tests
> > >>
> > >> Scott
> > >>
> > >>
> > >> ps's
> > >>
> > >> 1980's
> > >> "I believe that the final bug in TeX was discovered and removed on
> > >> November 27, 1985. But if, somehow, an error still lurks in the code,
> > >> I shall gladly pay a finder's fee of $20.48 to the first person who
> > >> discovers it. (This is twice the previous amount, and I plan to double
> > >> it again in a year; you see, I really am confident!) "
> > >> Don Knuth
> > >>
> > >> 2010
> > >> http://www-cs-staff.stanford.edu/~uno/abcde.html#texbk<http://www-cs-staff.stanford.edu/%7Euno/abcde.html#texbk>
> > <http://www-cs-staff.stanford.edu/%7Euno/abcde.html#texbk>
> > >> If you do succeed in finding a previously undiscovered bug in the
> > >> programs for either TeX or METAFONT, I shall gladly reward you with
> > >> 0x$80.00 ($327.68) at the Bank of San Serriffe. Corrections to errors
> > >> in The TeXbook or The METAFONTbook are worth 0x$1.00 ($2.56),
> > >> as in all my other books.
> > >>
> > >> The Bank of San Serriffe
> > >> http://www-cs-staff.stanford.edu/~uno/news08.html<http://www-cs-staff.stanford.edu/%7Euno/news08.html>
> > <http://www-cs-staff.stanford.edu/%7Euno/news08.html>
> > >>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 22 2010 - 10:00:02 PST
