[gmx-developers] rlist larger than L/2 in simple neighbor search

Gerrit Groenhof ggroenh at gwdg.de
Wed Oct 13 08:33:33 CEST 2010


  On 10/12/2010 06:49 PM, Lee-Ping Wang wrote:
>
> Hi there,
>
> For the past few months, I've been adding a charge equilibration model 
> to GROMACS (to be specific, QTPIE -- a refinement of QEq).  For the 
> model to work properly, each atom must "see" each other atom in the 
> electrostatic interaction (it is a screened Coulomb interaction). 
>  This is easy enough to do with pbc = no; I just set all the cutoffs 
> to zero, and add a new neighbor-list that includes excluded atom pairs.
>

Since we'd be interested in that, I would appreciate if you can keep us 
informed of your progress.

> Now I would like to run the simulation with PBC turned on, which means 
> either implementing Ewald summation or using cutoffs for the 
> electrostatic interaction.  When cutoffs are turned on (with or 
> without PBC), the model goes haywire even with very long cutoff 
> lengths.  I haven't implemented Ewald summation for the screened 
> Coulomb interaction, and I'm not sure if it's worth the effort if an 
> easier fix is possible.
>

If I recall correctly, the screened Coulomb here means the overlap 
integral between s-type Slater functions. This interaction behave as a 
normal coulomb at large distances, so that coudl explain the issues with 
increasing the cut-off. But an Ewald expression will be difficult as 
well, since  the all pairs-wise interactions are required to compute the 
charge flow parameters. I have so far only seen it applied to molecules. 
For non bonded system like a box of water, a direct charge flow between 
atoms far apart is unlikely though. Could one not simply scale also the 
charge transfer variables to zero with distance as well?
>
> As a quick fix, I changed the simple neighbor-searching code to set 
> rcut = 1000000 when QTPIE is turned on.
>
> I am worried about the other possible consequences of my change; will 
> this adversely affect the molecular dynamics or create artifacts in 
> some unexpected way?
>
You will get the ordinary artefacts caused by cutoff, like ordering etc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20101013/ca336902/attachment.html>


More information about the gromacs.org_gmx-developers mailing list