[gmx-users] refcoord-scaling

Chetan Mahajan chetanvm10 at gmail.com
Tue May 13 08:04:35 CEST 2014


Thanks, Mark. What do you mean by buffer in your last sentence?


On Tue, May 13, 2014 at 1:00 AM, Mark Abraham <mark.j.abraham at gmail.com>wrote:

>
> On May 13, 2014 7:34 AM, "Chetan Mahajan" <chetanvm10 at gmail.com> wrote:
> >
> > Thanks, Mark. With timestep to be 1 fs (instead of 2 fs) in production
> run, job is running fine without blowing up. (equilibration run also
> contains timestep to be 1 fs and refcoord-scaling option is set to "com").
> However, time step to 1 fs in production run does not affect water and its
> relaxation, since water is kept rigid.
>
> Sounds like maybe the TiO2 model is not stable.
>
> > Now I have a question: Having to make nstlist option as "1" or reducing
> timestep to "1 fs" to make the job run without blowing up, does this mean
> everything scientifically is okay? In other words, do these changes
> suppress any other serious error, with respect to forcefield choice eg.?
>
> Validating a model can only be done a posteriori, by observing whether it
> reproduces the right ensemble. Reducing the time step generally improves
> the quality with which the integrator produces the (shadow) ensemble (but
> there are lots of subtle effects) - it says nothing about the quality of
> the ensemble, though.
>
> Nstlist should never need to be 1 if you are using a buffer in that list;
> doing so will generally improve performance. Details vary with your
> nonbonded setup.
>
> Mark
>
> > Thanks
> > Chetan
> >
> >
> > On Mon, May 12, 2014 at 11:53 PM, Mark Abraham <mark.j.abraham at gmail.com>
> wrote:
> >>
> >>
> >> On May 10, 2014 10:00 PM, "Chetan Mahajan" <chetanvm10 at gmail.com>
> wrote:
> >> >
> >> > Hi Mark
> >> >
> >> > We discussed this "refcoord scaling=com not working" quite a bit.
> With new version of gromacs 4.6.5, it seemed that com option is working
> fine. However, I later found out that it is only for equilibration run and
> system does blow up (domain decomposition error) in production run. Again
> to revise: I have a system consisting of 13133 atoms ( A TiO2 crystal ( 720
> Ti) , 3656 water molecules, 1 formate ion, 1 sodium ion). Atoms in TiO2
> crystal are held by position restraints.
> >>
> >> Doing something artificial during equilibration and then turning it off
> can lead to abrupt changes of behavior because you were not equilibrated at
> the new regime. If you have a valid model for the crystal, you should be
> able to equilibrate without needing to use artificial restraints that were
> never designed for your use case. That might mean tiny time steps to relax
> water molecules, or gradual heating stages, or taking care to choose a
> valid volume in the first place.
> >>
> >> > In the following you had made a comment that multiple COM and PBC may
> not be working well with each other. WHy did you think it's a case of
> "multiple" com of TiO2?  I am asking this, since in my TiO2 crystal, we are
> not defining any bonds between Ti and O, although we are defining entire
> TiO2 crystal to be one molecule. So, we can think of only 1 com.
> >>
> >> Depends how you implemented the crystal. If there's lots of repeated
> TiO2 moleculetypes, or such, then there are multiple com because grompp
> doesn't get told about the higher-order picture.
> >>
> >> Even if you have a single molecule for the whole crystal, I would not
> bet that the implementation of position restraints in NPT is well tested in
> the case of a restrained atom crossing a periodic boundary. Probably only
> compact protein solutes far from boundaries were tested. That might not be
> relevant in your case, and it might be implemented "right" after all, but
> you are warned that you should not blindly expect too much, here.
> >>
> >> Mark
> >>
> >> > Thanks
> >> > Chetan
> >> >
> >> >
> >> >
> >> > On Mon, Mar 24, 2014 at 4:16 AM, Mark Abraham <
> mark.j.abraham at gmail.com> wrote:
> >> >>
> >> >> On Mar 24, 2014 1:10 AM, "Chetan Mahajan" <chetanvm10 at gmail.com>
> wrote:
> >> >> >
> >> >> > Dear all:
> >> >> >
> >> >> > I am trying to get a simulation of water solvated titanium oxide
> running.
> >> >> > When 'all' option is used for refcoord-scaling, simulation runs ok.
> >> >> > However, when 'com' option is used for refcoord-scaling, simulation
> >> >> crashes
> >> >> > with any of the following errors. Could anyone explain to me why
> is this
> >> >> > happening
> >> >>
> >> >> See the description of com. You didn't tell us what you were
> restraining,
> >> >> so it's hard to help. But I can see multiple com of tio2 and PBC not
> >> >> working well together, particularly if you box size is far from best.
> >> >>
> >> >> > or when each of the options such as 'all', 'com' and 'no' is used?
> >> >>
> >> >> When you really care about your starting position and need to
> equilibrate
> >> >> in NPT.
> >> >>
> >> >> Mark
> >> >>
> >> >> > Thanks a lot!
> >> >> > regards
> >> >> > Chetan
> >> >> >
> >> >> >
> >> >> > Errors:
> >> >> >
> >> >> > X particles communicated to PME node Y are more than a cell length
> out of
> >> >> > the domain decomposition cell of their charge group
> >> >> >
> >> >> > This is another way that mdrun tells you your system is blowing
> >> >> > up<http://www.gromacs.org/Documentation/Terminology/Blowing_Up>.
> >> >> > In GROMACS version 4.0, domain decomposition was introduced to
> divide the
> >> >> > system into regions containing nearby atoms (for more details, see
> the
> >> >> > manual <http://www.gromacs.org/Documentation/Manual> or the
> GROMACS 4
> >> >> > paper<http://dx.doi.org/10.1021/ct700301q>).
> >> >> > If you have particles that are flying across the system, you will
> get this
> >> >> > fatal error. The message indicates that some piece of your system
> is
> >> >> > tearing apart (hence out of the "cell of their charge group").
> Refer
> >> >> > to the Blowing
> >> >> > Up <http://www.gromacs.org/Documentation/Terminology/Blowing_Up>
> page for
> >> >> > advice on how to fix this issue.
> >> >> >
> >> >> >
> >> >> > A charge group moved too far between two domain decomposition
> steps.
> >> >> > --
> >> >> > 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-usersor
> >> >> send a mail to gmx-users-request at 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-usersor send a mail to
> gmx-users-request at gromacs.org.
> >> >
> >> >
> >
> >
>


More information about the gromacs.org_gmx-users mailing list