[gmx-users] refcoord-scaling

[Chetan Mahajan]

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.

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.?

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-users or
> >> 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-users or
> send a mail to gmx-users-request at gromacs.org.
> >
> >
>