# [gmx-users] minimization -- bugzilla or general advice?

Berk Hess gmx3 at hotmail.com
Thu Mar 27 15:15:03 CET 2008

```

> Date: Thu, 27 Mar 2008 06:41:12 -0700
> From: dmobley at gmail.com
> To: gmx-users at gromacs.org
> Subject: Re: [gmx-users] minimization -- bugzilla or general advice?
>
> Berk,
>
> > The problem could be in the constraints.
> > Gromacs 3 constrains the forces during EM by adding c*f to the coordinates,
> > constraining those and then dividing the constraint displacement by c.
> > This limits the accuracy.
> >
> > In Gromacs 4 I have implemented force constraining for LINCS and SETTLE.
> > This seems to improve the accuracy a lot.
>
> I'm running without constraints. Can you explain in a little more
> detail what you mean here? c*f, where c is what? Why is this done? I
> know "to constrain the forces" but it's not clear to me what the
> incentive is.

I assume you are using a rigid water model, and thus constraints via SETTLE.

Constraining is required to measure the size of the force (for convergence and
step size adjustment) and to make correct steps without enormous extra
displacements in the direction of the force which could cause problems due
to non-linearity.
In Gromacs 3 we had only a coordinate version of SETTLE and LINCS
did not work well for "triangle constraints". So to constrain the force during EM
we needed to use only coordinates. The trick is to add c*f to the coordinates,
somewhat analogous to constraining velocities in leap frog, and then get the
force without constraint components as:
(x+c*f - constrained(x+c*f))/c
I chose c as the minimization step size divided by the maximum force.
But there are two issues here, for large c non-linearity problems
and for small c float/double accuracy issues.
The non-linearity issue could be causing your problems.

Although there is also another issue: water is difficult to minimize in general.

Berk.

_________________________________________________________________