[gmx-users] new features in 3.2 ?

[Erik Lindahl]

Hi Michael,

We should hopefully have a new-feature summary pretty soon.
>
>
> 1) In the code I saw some boolean variables that sound
> as if continuum electrostatics/implicit solvent were available
> in gromacs now, is this the case ?

No. This is infrastructure work for upcoming stuff, but 3.2 is intended 
as a maintenance release, so we did not want to change too much. It's 
coming, though :-)

>
> 2) in previous mails in this list the developers talked
> about some efforts to implement the calculation of
> electrostatic LR interaction energies (i.e. calculate the
> long range contribution to the interaction energy between
> two energy groups), at what stage are these efforts ?
>

Will be in 4.0.

> 3) I'd like to know the exact meaning of the parameter
> "table-extension"
> In the docu it says:
> "Extension of the non-bonded potential lookup tables beyond the
> largest cut-off distance"
> To which of the Coulomb/VdW + cutoff/shift/switch/PME
> combinations does this apply (it cannot apply, e.g., to
> shift because here this value is already determined to be
> rlist-rcoulomb(or rvdw), is it not ?)
>

This is more of a technical detail, it should not change simulation 
results. When you use tables, you need to be sure that the table data 
in memory extends further than the largest possible pairwise distance 
between atoms, or you risk a segmentation fault.

The positions are checked when you do neighborsearching, and particles 
reset in the box. Normally, something is very, very bad if your atom is 
moving more than say a nanometer in those ten steps, so it should not 
be an issue (we used to have a 'buffer' zone of about 1 nanometer 
beyond the largest cut-off).

However, you could imagine a case where you wanted very large charge 
groups, or that you were using other units, or something else. In any 
case, there wasn't any reason why you shouldn't be able to change it if 
you wanted to. For normal stuff you can just forget about it.

In the case of switch/shift the table will be filled with "0" beyond 
the cutoff - it is just to avoid a segfault.

(Btw, an obvious question might be: But why don't we check it in the 
innerloop? The problem is that it would cause a huge latency-stall and 
decrease performance significantly if we were to do that for all pairs 
in a system each step).

Cheers,

Erik