[gmx-users] Shift Electrostatic Summation
Mark.Abraham at anu.edu.au
Wed Apr 15 06:21:08 CEST 2009
Shuangxing Dai wrote:
> ----- Original Message ----- From: "Mark Abraham" <Mark.Abraham at anu.edu.au>
> To: "Discussion list for GROMACS users" <gmx-users at gromacs.org>
> Sent: 14 April, 2009 8:01 PM
> Subject: Re: [gmx-users] Shift Electrostatic Summation
>> Shuangxing Dai wrote:
>>> Thank you for your help. Yes, when I found the user define part for
>>> electrostatics, I hope I can use this part since the analytic form of
>>> my potential is known. However, since there is a self energy term
>>> exist and then the whole energy cannot be decomposed to pair
>>> interactions because I cannot specify how much to each pair since the
>>> number of neighbours is unkown. That is why I am confused. So I still
>>> need an new electrostatic summation similiar to shift, not just a new
>>> pair interaction.
>> The number of neighbours is known at run-time. However, I still don't
>> see why this matters - see
> OK, the self energy is assigned for each ion. If I want to decompose the
> potential form of total energy to summation of pair potential, I should
> devide the self term by number of neighbours and assigned to each pair.
> So I cannot use user define potential for my problem.
You can use a user potential if the dependence of the force and/or
potential on r and N is sufficiently separable. The number of neighbours
is known inside the inner nonbonded loops, because they're looping over
the neighbours of each particle. So you merely do a table lookup before
or after some function of N is applied to some function of r. Thus the
only work you'd need to do is to construct the correct form of tables,
and add in the arithmetic concerning N.
Per my advice in that previous thread, you should read and understand
the code for the nonbonded kernel for a straight cutoff, compare that
with non-table-lookup Ewald, and compare that with table-lookup Ewald.
Also heed the advice Berk gave you.
You've still never explained why N in the formula in that previous
thread is the number of neighbours of a given particle, not the number
of particles in the system - but that's your problem.
More information about the gromacs.org_gmx-users