[gmx-users] new features in 3.2 ?
lindahl at csb.stanford.edu
Thu Feb 5 16:53:01 CET 2004
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
> 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).
More information about the gromacs.org_gmx-users