[gmx-users] Error after trjconf processing

Mark Abraham mark.j.abraham at gmail.com
Fri May 3 15:11:07 CEST 2013


EM has no velocities, by definition. Does the EM mdrun write a .gro file
with velocities? If so, that's a bug.


On Fri, May 3, 2013 at 2:51 PM, James Starlight <jmsstarlight at gmail.com>wrote:

> I've noticed that the minimized conformers no longer has the velocities in
> gro file (and npt rus without warnings in that case) in comparison to the
> not-minimized structures ( where velocities were present and gromp sent
> warnings). All pbc options lare the same for all conformers and box vectors
> correctly defined in boundary regions.
>
> But after npt equilibration of the minimized structures ( velocities again
> present in the gro file) my system have crushed at the beginning of the
> production run. So the problem in the velocities set which wre taken from
> the initial pulling run (the same for each conformers).


Huh? After EM there should be no velocities, and you should instruct the
grompp before your equilibration to generate new ones regardless.


> Should I re-assign
> velocities for each conformer (addition nvt run) to fix it ?
>

There seems to be no purpose to trying to start a new simulation from some
configuration, doing EM on it, and then trying to equilibrate starting with
the pre-EM velocities (even if it is possible, which I do not think it
should be). The energy distributions are guaranteed to be mutually
inconsistent.

Mark


>
> James
>
> 2013/5/3 Mark Abraham <mark.j.abraham at gmail.com>
>
> > On Fri, May 3, 2013 at 11:15 AM, James Starlight <jmsstarlight at gmail.com
> > >wrote:
> >
> > > Mark,
> > >
> > > thanks for suggestions
> > >
> > > as I've told previously I've removed pbc via trjconv witout -pbc mol
> and
> > > -pbc
> > > nojump flags
> >
> >
> > I didn't see anything like that in this thread...
> >
> >
> > > (the same way I found in Justin's umbrella tutorial where
> > > conformers were extracted from pulling trajectory). Might it be source
> of
> > > the some artifacts with pbc ?
> > >
> >
> > Don't know. Look at your files and see what's there :-)
> >
> >
> > > so if I understood correctly subsequent minimization (with maxwarn 1
> > flag)
> > > restored original pbc (based on box vectors defined in gro file )
> because
> > > in next production MD there were no warnings
> > >
> >
> > The PBC was always there. The question is likely whether the code assumes
> > molecules have coordinates that do not straddle the current box, or not.
> > mdrun goes to the expense of ensuring that it does it correctly, but
> there
> > are countless other points where the code may or may not still be doing
> > something that was correct at some point in the last 15 years under
> certain
> > assumptions, but may not be correct now or under new conditions...
> >
> > Mark
> >
> > 2013/5/3 Mark Abraham <mark.j.abraham at gmail.com>
> > >
> > > > Trajectory frames written by mdrun are not post-processed to guess
> how
> > > you
> > > > would like PBC to be treated for whatever purpose you have next. So
> if
> > a
> > > > molecule straddles a periodic boundary given the current center
> > position,
> > > > that's what it looks like. If there are things you want to do, then
> > > there's
> > > > the instructions at
> > > >
> > > >
> > >
> >
> http://www.gromacs.org/Documentation/Terminology/Periodic_Boundary_Conditions
> > > > .
> > > >
> > > > In turn, it seems grompp applies a whole collection of basic checks,
> > and
> > > it
> > > > seems that one of them might not be sufficiently PBC-aware. Such
> checks
> > > > appropriate for a normal grompp workflow, where this is the first
> point
> > > the
> > > > GROMACS machinery gets to see what you intend to do and is the point
> > > where
> > > > it can help you ensure sanity. It seems there's room for a small
> > > > improvement, too.
> > > >
> > > > If the subsequent MD works, then you need have no concern, but if you
> > > want
> > > > to post-process your trjconv frames so that the molecules are whole,
> > you
> > > > will suppress this warning the "correct" way.
> > > >
> > > > Mark
> > > >
> > > > On Fri, May 3, 2013 at 8:18 AM, James Starlight <
> > jmsstarlight at gmail.com
> > > > >wrote:
> > > >
> > > > > Dear Gromacs users!
> > > > >
> > > > > I have performed long md run. From the production trajectory by
> means
> > > of
> > > > >
> > > > > trjconv -f md_.trr -s cam.tpr  -dt 10 -e 300 -sep -o ./pdbs/.pdb  #
> > > > extract
> > > > > conformers from first 300 ps each 10ps steps
> > > > >
> > > > >
> > > > > I've extracted 10 conformers in the desired time step
> > > > >
> > > > > Than when I perform MD on each conformer I obtain error (when I
> > loaded
> > > in
> > > > > grompp  conformer from the initial run I have no such error)
> > > > >
> > > > > Number of degrees of freedom in T-Coupling group rest is 130551.00
> > > > > Largest charge group radii for Van der Waals: 8.895, 7.586 nm
> > > > > Largest charge group radii for Coulomb:       8.895, 8.474 nm
> > > > >
> > > > > WARNING 1 [file ./mdps/minim.mdp]:
> > > > >   The sum of the two largest charge group radii (17.368397) is
> larger
> > > > than
> > > > >   rlist (1.000000)
> > > > >
> > > > >
> > > > > Finally after minimization of each conformer with the same R_list
> > (with
> > > > > maxwarn 1 flag) and starting new MD on the minimizing conformer I
> > have
> > > no
> > > > > such error:
> > > > > Largest charge group radii for Van der Waals: 0.241, 0.237 nm
> > > > > Largest charge group radii for Coulomb:       0.241, 0.237 nm
> > > > >
> > > > > Why this error have occurred (with no minimized conformers) and how
> > it
> > > > > could be fixed correctly ?
> > > > >
> > > > > James
> > > > > --
> > > > > gmx-users mailing list    gmx-users at gromacs.org
> > > > > http://lists.gromacs.org/mailman/listinfo/gmx-users
> > > > > * Please search the archive at
> > > > > http://www.gromacs.org/Support/Mailing_Lists/Search before
> posting!
> > > > > * Please don't post (un)subscribe requests to the list. Use the
> > > > > www interface or send it to gmx-users-request at gromacs.org.
> > > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > > > >
> > > > --
> > > > gmx-users mailing list    gmx-users at gromacs.org
> > > > http://lists.gromacs.org/mailman/listinfo/gmx-users
> > > > * Please search the archive at
> > > > http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> > > > * Please don't post (un)subscribe requests to the list. Use the
> > > > www interface or send it to gmx-users-request at gromacs.org.
> > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > > >
> > > --
> > > gmx-users mailing list    gmx-users at gromacs.org
> > > http://lists.gromacs.org/mailman/listinfo/gmx-users
> > > * Please search the archive at
> > > http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> > > * Please don't post (un)subscribe requests to the list. Use the
> > > www interface or send it to gmx-users-request at gromacs.org.
> > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> > --
> > gmx-users mailing list    gmx-users at gromacs.org
> > http://lists.gromacs.org/mailman/listinfo/gmx-users
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> > * Please don't post (un)subscribe requests to the list. Use the
> > www interface or send it to gmx-users-request at gromacs.org.
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> --
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> * Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>



More information about the gromacs.org_gmx-users mailing list