[gmx-users] Re PME question in GMX4.6.5

Mark Abraham mark.j.abraham at gmail.com
Thu Jan 15 10:41:00 CET 2015


Hi,

You've taken my remark out of context, which was that of a two-particle
system whose inter-particle distance was within the cutoff. There, the
long-range component is doing fewer things.

Mark

On Thu, Jan 15, 2015 at 1:25 AM, Tom <dnaafm at gmail.com> wrote:

> Mark,
>
> Thanks for your reply!
>
> I actually found this disscussion about PME, which might be from you?
> https://groups.google.com/forum/#!topic/archive-gmx-users/VmK7H5vF9cY
>
> you were saying:"The total energy for that interaction is distributed over
> the Coul-SR and *Coul. recip terms (which is how PME works...), which you
> will note is approximately equal to Coul-SR for coulombtype cut-off*."
>
> That is why I run these test runs and found that Coul.recip from PME has
> big
> difference from Coul-SR from coulombytpe cut-off.
>
> Anyway, i will double check the menual and the source code as well your
> paper.
>
> Thomas
>
>
>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 13 Jan 2015 07:32:25 +0100
>> From: Mark Abraham <mark.j.abraham at gmail.com>
>> Cc: Discussion list for GROMACS users
>>         <gromacs.org_gmx-users at maillist.sys.kth.se>
>> Subject: Re: [gmx-users] PME question in GMX4.6.5
>> Message-ID:
>>         <CAMNuMAT7hyKHCLAqVtFOz4v7N9qzpU-MkyFY2=
>> HquJN6RTbLdg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> 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
>> >>
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>


More information about the gromacs.org_gmx-users mailing list