On Thu, May 17, 2007, Peter Z. Qin wrote:
> >
>
> I first applied budfix64 but it did not fix the problems. Following that,
> I compiled without optimizing. THAT WORKS!
If you want, the next thing to do is to try to figure out which routine doesn't
work with optimization turned on. Here is a suggested path, (for you or
someone else):
1. Do dhfr one step with verbose=2 in the &ewald namelist. Look at the
differences between optimized and unoptimzed code. If you are lucky, the
differences will be in the reciprocal contribution to the electrostatic
energy.
2. If so, try just compiling ew_fft.f (and/or ew_recip.f) at low
optimization, everything else at high optimzation. My guess is that ew_fft.f
is the culprit...there seem to be things in there that the intel optimizers
don't like.
3. Of course, if my guesses above are wrong, you may have to do some trial
and error searching around to find what is really going on. But having the
verbose output should be a big help in narrowing down the problem area.
>
> The tests of serail version all PASSED (except for the antechamber, which I
> will post in a separate email). Tests of parallel version of snader and
> sander.LES returned only one possible failure:
>
> [pzq.hpc-login1 pheTI]$ more out.p1.dif
> 190c190
> < Ewald error estimate: 0.5094E-16
> ---
> > Ewald error estimate: 0.0000
> [pzq.hpc-login1 pheTI]$
This is an insignificant difference.
....dac
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Sun May 20 2007 - 06:07:29 PDT
