[gmx-users] PME question in GMX4.6.5

[Mark Abraham]

On Tue, Jan 13, 2015 at 6:17 AM, Tom <dnaafm at gmail.com> wrote:

> Mark,
>
> Thanks for the discussion!
> Can you give me more detialed information?
>

Please start by reading the manual sections (4.8 and 3.17.5).


> Yes, I do need a higher speed so I choose the option to periodic
> electrostatic sum into two terms: SR & recip.
>
> Is there other more decent way to do it? Thanks!
>

No, but you can do PME differently, and perhaps better, for your simulation
system and your hardware. Shameless self-plug:
http://dx.doi.org/10.1002/jcc.21773, but mdrun does some of this for you,
these days.

This was what I used for PME
> -----------------------------
> nstlist                  = 10
> ns_type                  = grid
> rlist                    = 1.2
> rcoulomb                 = 1.2
> rvdw                     = 1.2
> ; Electrostatics
> coulombtype              = PME  ; Particle Mesh Ewald for long-range
> electrostatics
> ewald_geometry           = 3dc
> pme_order                = 4    ; cubic interpolation
> fourierspacing           = 0.12 ; grid spacing for FFT
> -------------------------------
>
> I gave a test by using different
> *Case 1) PME: **coulombtype = PME**; **rlist =1.2;  rcoulomb=1.2;
> rvdw=1.2*
>         Coulomb (SR) (= 3.88670e+05) *<* Coul. recip.(3.09251e+06)
> *Case 2) PME:  **coulombtype = PME**; **rlist =1.2;  rcoulomb=1.2;
> rvdw=1.2*
>         Coulomb (SR) (= 1.00323e+06) *<* Coul. recip.(2.47795e+06)
>

What's different between these two cases? (But doesn't matter, the real
issue is below)


> *Case 3) No PME:*   *coulombtype = cutoff;  rlist =1.2;  rcoulomb=1.2;
> rvdw=1.2*
>          Coulomb (SR) = 3.33299e+06
> *Case 4) NO PME:  coulombtype = PME**;  rlist =1.8;  rcoulomb=1.8;
> rvdw=1.8*
>         Coulomb (SR) = 3.99204e+06
>
> Even for same rlist, rcoulomb and rvdw, the value by using the cutoff  of
> 1. 2 (Coulomb (SR) =3.33299e+06) (see Case 1) is much larger than the value
> of  Coulomb (SR) (= 3.88670e+05)
> by using PME with *rlist =1.2;  rcoulomb=1.2; rvdw=1.2* (See Case 3).
> Why there is such big difference?
>

None of the above are meaningful to compare. By using plain cutoff, you are
neglecting an extremely large number of interactions, so it is not
surprising any numbers are different. By changing the size of the
short-range region, you are shifting computation from one part to another,
so it is not surprising that numbers are different.

If Coulomb (SR) with PME means the short-rang Coulombic within rcoulomb,
>

But it isn't. See equation 4.158 of manual.


> Coulomb (SR) with PME should very close to or equal to calculaton of the
> same cutoff without PME.
>

Nope. The short-ranged part is modified, and the long-range part corrects
for the short-range modification and the neglected long-range part of the
unmodified potential. People often speak loosely about this, unfortunately.

I assume the Coulomb SR in PME is calculated by explicit pairwise
> interaction like that of Cutoff
> and Recip part uses Fourier Conversion.
>

Yes, but the SR part is not 1/r any more.


> I am really wondering if it is due to bugs of PME for this version: 4.6.5.
>

Not on the available evidence.

>> I'll bet lunch that the input was not actually from the PME run ;-)
> We do need to use g_energy to output the total Coulombic interactions
> between certains objects
> in the system. Now the recip. part is much larger than SR part but the
> recip. part can not be reported
> by g_energy.
>

g_energy will report the reciprocal-space energy if the input file you gave
it had such a component. mdrun with PME wrote such a file. Your observation
is most consistent with not using the file you think you are using.

If you're wanting the reciprocal space component to be broken down by
energy group, then that's not available. Someone on this list once observed
that you can use mdrun -rerun creatively with various components charges
zeroed out in order to compute that break down. Whether that then
correlates with anything useful is... your problem.

Mark

Can you let us know if there is any wrong in our inputs for PME?
>
> Thanks!
>
> Tom
>
>
>
>> Message: 5
>> Date: Mon, 12 Jan 2015 18:44:56 +0100
>> From: Mark Abraham <mark.j.abraham at gmail.com>
>> To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>> Subject: Re: [gmx-users] PME question in GMX4.6.5
>> Message-ID:
>>         <
>> CAMNuMAREBb8Ny5KfOudKUX-gvwQHhOX6MRphDUfPkTtR5bHPag at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On Sat, Jan 10, 2015 at 5:58 PM, Tom <dnaafm at gmail.com> wrote:
>>
>> > Dear GMX and PEM experts,
>> >
>> > I am using gromacs 4.6.5.  My system is neutral charge (net charge=0).
>> > I used PME with the following options:
>> > -------------
>> > ; Electrostatics
>> > coulombtype              = PME  ; Particle Mesh Ewald for long-range
>> > electrostatics
>> > ewald_geometry           = 3dc
>> > pme_order                = 4    ; cubic interpolation
>> > fourierspacing           = 0.12 ; grid spacing for FFT
>> > --------------
>> >
>> > I noticed that for my system *with PME calculation *that value of
>> *Coulomb
>> > (SR) is much*
>> > *larger than Coul. recip*
>> > Coulomb (SR) (= 3.88670e+05) < Coul. recip.(3.09251e+06)
>> >
>> > Do you think if it is possible to have such as huge tail effects of
>> > Coulombic interactions?
>> >
>>
>> You chose a set of parameters that split the computation of the full
>> periodic electrostatic sum into two terms whose sum approximates the full
>> one while hopefully being cheaper to compute. The relative magnitude of
>> the
>> energies doesn't mean much of anything...
>>
>> (My systems consist of a neutral SAMs surface and water)
>> > Another problem is that g_energy of GMX4.6.5 only reports the value of
>> > Coulomb (SR) and
>> > does not report Coul. recip.
>> >
>>
>> I'll bet lunch that the input was not actually from the PME run ;-)
>>
>> I also used simple *cutoff* to calcualte coulombic:
>> > Coulomb (SR) = 3.99204e+06  *is the very close to the PME *calculation
>> of
>> > the total of Coulomb (SR) + Coul. recip.
>> >
>>
>> Great, but this is a totally different (and terrible) approximation.
>>
>> Mark
>>
>>
>> > Thanks a lot for your help!
>> >
>> > Thomas
>>
>> >
>>
>>
>>
>