http://bugzilla.ambermd.org/show_bug.cgi?id=12
case <case.scripps.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #4 from case <case.scripps.edu> 2008-02-26 09:07:30 PST ---
I have "fixed" this, by reverting force.f back to the logic it had in version 9
and earlier.
Basically, to correctly handle weight changes in parallel, you need to call
nmrcal() with *both* the "WEIT" and the "CALC" keywords on all threads. This
is true, even though there is nothing to "calculate", since the "CALC" call
handles some of the bookkeeping for weight changes.
I think the problem is mostly in how the "nstep" variable is handled, but the
long term solution is a more thorough rewrite than I want to do now. I believe
that what has been done in revision 9.64 to force.f revert us back to the
(well-tested?) situation that existed in earlier versions of Amber.
--
Configure bugmail: http://bugzilla.ambermd.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Wed Feb 27 2008 - 06:07:41 PST
