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 <[email protected]> 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 <[email protected]> >> Cc: Discussion list for GROMACS users >> <[email protected]> >> Subject: Re: [gmx-users] PME question in GMX4.6.5 >> Message-ID: >> <CAMNuMAT7hyKHCLAqVtFOz4v7N9qzpU-MkyFY2= >> [email protected]> >> Content-Type: text/plain; charset=UTF-8 >> >> On Tue, Jan 13, 2015 at 6:17 AM, Tom <[email protected]> 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 <[email protected]> >> >> To: Discussion list for GROMACS users <[email protected]> >> >> Subject: Re: [gmx-users] PME question in GMX4.6.5 >> >> Message-ID: >> >> < >> >> camnumarebb8ny5kfoudkux-gvwqhhox6mrphdufpkttr5bh...@mail.gmail.com> >> >> Content-Type: text/plain; charset=UTF-8 >> >> >> >> On Sat, Jan 10, 2015 at 5:58 PM, Tom <[email protected]> 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 >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> > -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to [email protected].
