Re: Kb, Ktheta values for TIP3P water model

From: Kenno Vanommeslaeghe (kvanomme_at_rx.umaryland.edu)
Date: Thu Aug 07 2014 - 15:08:39 CDT

On 08/07/2014 01:36 PM, Hadi wrote:
> He misunderstood my points

No, your points are quite clear, and inaccurate; see below.

> wanted to make me do an inappropriate action.

Oh, so humility is "inappropriate" now? And here I thought I'd seen it all
in this discussion...

> Now if one uses a force constant value of 0 in the parameter file:
-snip-
> The simulations become unstable.
-snip-
> Viswanath (the person who started the thread) was wondering what one
> should do in this case. So I suggested to use reasonable force constants.
-snip-
> Again, let me emphasize that the simulations become unstable, etc. if one
> does not use reasonable force constants. It does not matter whether one
> uses SHAKE or SETTLE algorithms.

You're still not fully getting it. rigidBonds effectively causes the force
constant to be *ignored* in favor of constraining the distance. The
confusion likely stems from the following two quirks:

(1) I just discovered that if NAMD detects a force constant of EXACTLY
ZERO, it will suppress rigidBonds for that degree freedom. I didn't know
this because I always use the CHARMM parameter files. However, contrary to
your claim, rigidBonds simulations will run stable and correctly with the
most _unreasonable_ X-H force constants (including 0.0001 or 10000 or even
-10000), just not 0.

(2) the issue Viswanath had when using a high force constant was the
*minimizer* crashing, *not* the MD simulation. I never used NAMD's
minimizer (I do my system preparation in CHARMM), but Viswanath's anecdote
suggests it does not support rigidBonds.

So, to be fair, your solution of using the "fallback" values is actually
the right one, *assuming* Viswanath did actually use rigidBonds (which we
don't know!) As the "fallback" force constants are reasonable, they are
not likely to destabilize the minimizer, and once the actual MD run
starts, all that matters is that they are not zero. In the end, it's only
your explanation of WHY your solution works that was incorrect. One might
say that's a detail, but understanding exactly what one's simulation is
doing is paramount to doing good science with it, and flinging around
wildly inaccurate claims ticks off the list's regulars. If I were to
falsely say: "your MC code is not correctly handling rigid molecules",
wouldn't you feel upset?

This archive was generated by hypermail 2.1.6 : Wed Dec 31 2014 - 23:22:42 CST