Re: [AMBER] Amber 14 w/ CUDA - unclear "make test"-errors

From: Ross Walker <ross.rosswalker.co.uk>
Date: Thu, 11 Feb 2016 07:31:54 -0800

Actually, looking more closely, the main failures shown here are all for IGB=8. This is because update.12 changed the GBNeck2 parameters and thus all IGB=8 results:

http://ambermd.org/bugfixes/14.0/update.12

It did not however update the test cases. So in this case the test suite is correct - IGB8 is now, as far as the test suite is concerned, giving incorrect answers. The IGB8 test output needs to be updated and the author of update.12 should make an additional update to fix this.

All the best
Ross

> On Feb 11, 2016, at 05:03, Jason Swails <jason.swails.gmail.com> wrote:
>
> On Thu, Feb 11, 2016 at 7:36 AM, Falko Jähnert <
> falko.jaehnert.biochemtech.uni-halle.de> wrote:
>
>> Dear Amberlings,
>>
>>
>>
>> at first, thanks a lot helping me out with my last problem „Howto cpptraj -
>> multiple trajin-commands in one line“. .Jean-Marc Billod: I did it your way
>> and this works just fine!
>>
>>
>>
>> Now I’ve got a little concern about the results of my installation of Amber
>> 14. The make test-procedure at the parallel installation level (both with 2
>> and 4 threads) went through without a single error, even without rounding
>> mistakes. After that i’ve compiled Amber 14 the usual way to gather
>> CUDA-support. Now the make test produce some rounding errors which are okay
>> (I hope), but also errors where lines one of the compared files (*.diff)
>> are
>> inserted and thus produce a lot of differences. If one compares the numbers
>> of the correctly aligned lines then everything is fine (I hope – again with
>> some rounding errors). To understand my problem better I attached the *log-
>> and the *.diff-files which are shortened to display only the unclear diffs.
>>
>>
>>
>> Can I ignore this diffs safely? If not, may someone provide any information
>> handling this problem?
>>
>
> ​This is a known deficiency in the CUDA testing infrastructure. All of the
> larger failures (i.e., that are not round-off) arise from stochastic
> methods (ntt=2 or ntt=3) where the random number stream is different on
> every GPU.
>
> While there is a way to fix it (and it is on the to-do list), it apparently
> hasn't been important enough to make it to the top yet.
>
> HTH,
> Jason
> ​
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber


_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Feb 11 2016 - 08:00:04 PST
Custom Search