Checked. Fixed. Thanks again!
João 2014-03-14 14:03 GMT+01:00 João Rodrigues <anar...@gmail.com>: > Hi Carsten, > > Thanks for the fix! > > Will run it today and get back to you with the results. > > Cheers, > > João > > > 2014-03-14 12:32 GMT+01:00 Carsten Kutzner <ckut...@gwdg.de>: > > Dear João, >> >> could you check whether >> >> https://gerrit.gromacs.org/#/c/3267/ >> >> fixes your problems with g_tune_pme? >> >> Thanks, >> Carsten >> >> >> >> On 13 Mar 2014, at 18:27, João Rodrigues <anar...@gmail.com> wrote: >> >> > Hi Carsten, >> > >> > Thanks for the reply and for the info on the rlist modification. >> > >> > I created the bug report - http://redmine.gromacs.org/issues/1460 - and >> > assigned it to you. I also set the priority to low, don't know if it >> > matters. >> > >> > Cheers, >> > >> > João >> > >> > >> > 2014-03-13 18:04 GMT+01:00 Carsten Kutzner <ckut...@gwdg.de>: >> > >> >> Dear João, >> >> >> >> On 13 Mar 2014, at 14:38, João Rodrigues <anar...@gmail.com> wrote: >> >> >> >>> Hi all, >> >>> >> >>> I've been playing with g_tune_pme (neat tool!) for the last couple of >> >> days. >> >>> If I understood correctly, it can also be used to iterate over >> different >> >>> rcoulomb values using the -rmin and -rmax options. Using the Verlet >> >> scheme >> >>> requires rvdw = rcoulomb, so I used the -scalevdw option (which >> should be >> >>> true by default) to keep these equal. This does not seem to happen.. >> >>> >> >>> The (partial) contents of a tpr file of such a failed run show the >> >>> following: >> >>> >> >>> verlet-buffer-drift = 0.005 >> >>> * rlist = 1.213* >> >>> rlistlong = 1.213 >> >>> nstcalclr = 15 >> >>> rtpi = 0.05 >> >>> coulombtype = PME >> >>> coulomb-modifier = Potential-shift >> >>> rcoulomb-switch = 0 >> >>> * rcoulomb = 1* >> >>> vdwtype = Cut-off >> >>> vdw-modifier = Potential-shift >> >>> rvdw-switch = 0 >> >>> * rvdw = 1.2* >> >>> >> >>> The original mdp has the following parameters: >> >>> >> >>> ; Neighborsearching >> >>> ns_type = grid ; search neighboring grid cels >> >>> nstlist = 15 ; 10 fs >> >>> *rlist = 1.2 ; short-range neighborlist cutoff (in >> >> nm)* >> >>> *rcoulomb = 1.2 ; short-range electrostatic cutoff >> (in >> >> nm)* >> >>> *rvdw = 1.2 ; short-range van der Waals cutoff >> (in >> >> nm)* >> >>> cutoff-scheme = Verlet >> >>> >> >>> ; Electrostatics >> >>> coulombtype = PME ; Particle Mesh Ewald for long-range >> >>> electrostatics >> >>> pme_order = 4 ; cubic interpolation >> >>> fourierspacing = 0.16 ; grid spacing for FFT >> >>> >> >>> I searched a bit in the source code of gmx_tune_pme.c (4.6.5) and >> found >> >>> that the only check done between these parameters (rvdw and rcoulomb) >> is >> >> if >> >>> rvdw != rcoulomb in the original file, keep them as is (line 875). >> Other >> >>> than that, rvdw is checked against rlist to ensure that it keeps the >> >>> highest value of the two (rvdw >= rlist) (line 1012). This seems to >> make >> >>> sense since rlist was modified based on rcoulomb, in case of plain PME >> >>> (line 1004). However, this only ensures both values are equal if the >> new >> >>> rcoulomb is larger than the original. In case we start with rcoulomb >> 1.2 >> >>> and ask g_tune_pme to range from 1.0 to 1.4, those below 1.2 will >> fail. >> >> You are right, this is a bug in g_tune_pme. Could you please file this >> >> issue in http://redmine.gromacs.org and put me as assignee? >> >> >> >> Thanks for reporting this! >> >> >> >>> Also, why is my rlist changing since it is equal to rcoulomb? It >> should >> >> be >> >>> kept the same (line 1004) right? >> >> This is a feature of the Verlet scheme, see >> >> http://www.gromacs.org/Documentation/Cut-off_schemes >> >> >> >> Best, >> >> Carsten >> >> >> >> >> >> >> >> >> >> -- >> >> Dr. Carsten Kutzner >> >> Max Planck Institute for Biophysical Chemistry >> >> Theoretical and Computational Biophysics >> >> Am Fassberg 11, 37077 Goettingen, Germany >> >> Tel. +49-551-2012313, Fax: +49-551-2012302 >> >> http://www.mpibpc.mpg.de/grubmueller/kutzner >> >> http://www.mpibpc.mpg.de/grubmueller/sppexa >> >> -- >> >> 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 gmx-users-requ...@gromacs.org. >> >> >> > -- >> > 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 gmx-users-requ...@gromacs.org. >> >> -- >> 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 gmx-users-requ...@gromacs.org. >> > > -- 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 gmx-users-requ...@gromacs.org.