CHARMM Development Project Forums CHARMM Community Bug Reports & Fixes c31a1 minimizer and KE diffs from c30b1

In trying to verify c31a1, I get many tests with unacceptable results compared to c30b1. I hope that someone might know the source of these diffs so that we can either fix the problem or certify that the new and different results are correct for c31a1. If anyone does know about these diffs, please save me a lot of time searching for the source, thanks!

Minimizer:
Many tests have diffs that start with minimization. Once the minimizer has given a different result, the rest is different, of course.
In particular it appears that the steepest descent minimizer is causing the problem in most, if not all, cases.

KE:
Many of the tests fail in dynamics because the initial KE is different.

c25test: hrbestfit and rpath
Both have unacceptable test first results.

THere are other diffs that I am still characterizing, but the first two above cause the lion's share of the diffs.

Thanks,
Mike

One more thing......about this forum
Is there a way to have activity on the forum reflected into email so that
we can be aware of activity without having to check via a web browser.
For me, that is going to be a tough habit to start. It is much more likely that I will be responding if I am prompted by email when there is activity that is relevant to me.

Mike,
There's a bug in the rpath code (energy good but forces trashed). We've been working on this code...

Bernie

regarding the minimizer/steepest descent method:

I think that it is broken, but am not sure. The result that sd gives is higher
in energy than the same routine in c30b1.

For now, my fix is to put the c30b1 steepd.src into c31a1. It compiles and gives identical results for all related tests as c30b1.

Again, I only think it is broken, the new code may be more right (is that possible, degrees of rightness?) than the old one. It would certainly be nice if the new stuff had ##IF's around it so we could turn it off at least for testing purposes.

How shall we determine which is correct?

As an aside, unless it was wrong, what is the motivation for changing steepest descent? It already gets you close rather quickly, about all you would expect for sd method anyway. Why refine a crude method that is supposed to be no more than crude and fast? Was it broken for some cases?

Apologies for the wordiness, please advise or discuss where we should go with this problem. Has the new steepd code result been verified as correct and somehow significantly superior to the old steepd?

If the new stuff is correct and the old code was wrong, then we should only compare c31a1 results with c31a1 and newer, right?

Cheers,
Mike

Kinetic Energy:
Many of the tests were not giving the same answers as c30b1 and
it appeared that the trouble had to do with the KE. It turns out that all
the tests that were different were doing Langevin dynamics.
There is a change in dynamc.src which changes the dynamics for
lang method.

Thus we need to compare to c31 results only for all those tests.
I would like to go with Scott Brozell's suggestion that each
release of charmm come with a set of test output that are deemed to be
correct so we can diff against those.

Mike