[gmx-users] gromacs.org_gmx-users Digest, Vol 117, Issue 17
Cara Kreck
cara_a_k at hotmail.com
Fri Jan 10 09:43:56 CET 2014
When you run make_ndx there is a list of commands provided that allow you to pick out the atoms you want. These atoms are then used to create new groups in your index file. Further explanations and examples are provided if you enter h.
nr : group ! 'name' nr name 'splitch' nr Enter: list groups
'a': atom & 'del' nr 'splitres' nr 'l': list residues
't': atom type | 'keep' nr 'splitat' nr 'h': help
'r': residue 'res' nr 'chain' char
"name": group 'case': case sensitive 'q': save and quit
'ri': residue index
If you know that all of your water oxygen atoms are called OW, the easiest way to select them out is to simply type:
a OW
For more complex situations you should have a thorough read of the 'h' output.
Hope that helps,
Cara
> Date: Fri, 10 Jan 2014 09:41:34 +0530
> From: 18crown10 at gmail.com
> To: gromacs.org_gmx-users at maillist.sys.kth.se
> Subject: Re: [gmx-users] gromacs.org_gmx-users Digest, Vol 117, Issue 17
>
> Dear Abijit
> Thank you for your response.
> Means first
> make_ndx -f traj.trr -s topol.tpr -o index.ndx
> here i canl select "SOL" group for water but how to select "O" atom only
> not clear
> then run
> g_rdf -n index -o rdf.xvg
>
> but if i select only "SOL" group
> how i will get RDF of Zn-O means distribution of O atom surrounding Zn
> am a bit confused. could you please write down the commands.
>
> warm regards
>
> MALI
>
> On Fri, Jan 10, 2014 at 3:22 AM, <
> gromacs.org_gmx-users-request at maillist.sys.kth.se> wrote:
>
> > Send gromacs.org_gmx-users mailing list submissions to
> > gromacs.org_gmx-users at maillist.sys.kth.se
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> > or, via email, send a message with subject or body 'help' to
> > gromacs.org_gmx-users-request at maillist.sys.kth.se
> >
> > You can reach the person managing the list at
> > gromacs.org_gmx-users-owner at maillist.sys.kth.se
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of gromacs.org_gmx-users digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: pull_geometry=direction (Christopher Neale)
> > 2. Re: Overriding Wildcard dihedraltypes (Mark Abraham)
> > 3. RDF of Zn_water system using VMD/g_rdf (M S)
> > 4. Re: RDF of Zn_water system using VMD/g_rdf (abhijit Kayal)
> > 5. Re: Overriding Wildcard dihedraltypes (hubert santuz)
> > 6. Re: g_anaeig, entropy (David van der Spoel)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 9 Jan 2014 16:32:27 +0000
> > From: Christopher Neale <chris.neale at alum.utoronto.ca>
> > To: "gmx-users at gromacs.org" <gmx-users at gromacs.org>
> > Subject: Re: [gmx-users] pull_geometry=direction
> > Message-ID:
> > <
> > 73733370c76c466583ceaa4f2041076a at BLUPR03MB184.namprd03.prod.outlook.com>
> >
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Try using
> > pull_geometry = direction-periodic
> >
> > For more details, see http://bugzilla.gromacs.org/issues/1352
> >
> > Chris.
> > ________________________________________
> > From: gromacs.org_gmx-users-bounces at maillist.sys.kth.se <
> > gromacs.org_gmx-users-bounces at maillist.sys.kth.se> on behalf of Lalita
> > Shaki <lalitashaky at gmail.com>
> > Sent: 09 January 2014 10:34
> > To: gmx-users
> > Subject: [gmx-users] pull_geometry=direction
> >
> > Dear gromacs users,
> >
> > I have been working on a pulling simulation of the unfolding of a protein
> > and I have found out that went using pull_geometry=direction the code
> > checks at each time step if the groups distance is higher than 0.49 each
> > of the dimensions of the box. If the distance is higher that 0.49 of at
> > least one of the dimensions the simulations ends in an error. So pretty
> > much when you want to unfold a protein you would have to use a really large
> > cubic box.
> >
> > My question is if someone knows why gromacs check the magnitude of the
> > distance again the dimension of the box and does not check each of the
> > components of the distance vector to it correspondent dimension of the box.
> > I think this will also avoid the problem of miss calculating the
> > pull-reference distance and at the same time will permit to run
> > calculations with a rectangular box.
> >
> >
> > Thank you
> >
> > lalita
> >
> > --
> > Lalita S. Uribe.
> > European Master in Theoretical Chemistry and Computational Modeling.
> > PhD student. Johannes Gutenberg-Universit?t Mainz
> > --
> > 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.
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 9 Jan 2014 18:29:48 +0100
> > From: Mark Abraham <mark.j.abraham at gmail.com>
> > To: Discussion list for GROMACS users <gmx-users at gromacs.org>
> > Subject: Re: [gmx-users] Overriding Wildcard dihedraltypes
> > Message-ID:
> > <CAMNuMATV8r7EBd1=
> > 03zXSAfM1T-oSaByH93BeFXbe6bP7GDjRg at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Thu, Jan 9, 2014 at 5:51 PM, hubert santuz <hubert.santuz at gmail.com
> > >wrote:
> >
> > > Hi,
> > >
> > > First, thanks for your detailed response.
> > >
> > > Thanks for the question, and particularly the detail. It seems that you
> > >> are
> > >> trying use a [dihedraltypes] section in my_molecule.itp, which is
> > >> generally
> > >> a bad idea, because all such directives must appear before the first
> > >> [molecule] directive, which defeats the point of molecule.itp files
> > being
> > >> somewhat movable. Because of that intention for molecule.itp files,
> > >> there'd
> > >> be no reason to have separate [dihedraltypes] sections that should be
> > >> logically treated together, so the code assumes such sections are
> > >> separable, and so you get unintended behaviour (perhaps particularly
> > with
> > >> wildcard atom types, and/or type 9 dihedrals) unless you change
> > >> ffbonded.itp like you have now done.
> > >>
> > > By trying to simplify my problem, I have misleading you.
> > > In fact, I have 2 itp files for my molecule (its is the cholesterol) :
> > > - One containing all the *types sections [atomtypes, bondtypes,
> > > dihedraltypes] (params_chol.itp)
> > > - The second one is a 'regular' itp file containing [molecules, atoms,
> > > bond ] sections. (cholesterol.itp)
> > > So, in my topol. top, I have in reality this :
> > >
> > > #include "charmm36.ff/forcefield.itp"
> > > #include "params_chol.itp"
> > > #include "cholesterol.itp"
> > >
> > > My [dihedraltypes] directive is then before the [molecule] directive.
> > > I have to do this because I have 2 new atoms for this molecule so I need
> > > to declare them somewhere. Therefore, I also need to declare the
> > bondtypes,
> > > angletypes and dihedraltypes associated with these 2 new atoms.
> > > All is working well except this dihedral override.
> > > That's why I suspected a bug but maybe it is that part I'm not doing in
> > > the good way...
> >
> >
> > Yes, the above is more workable, but it has the same problem that
> > cholesterol.itp depends on correctly formed [dihedraltypes]. I think it is
> > likely that the implementation assumes you would not try to declare a set
> > of additive [dihedraltypes] in such a modular way, since the
> > copy-and-modify-ffbonded.itp procedure is available. Not ideal, but odds
> > are excellent it won't be fixed, either ;-)
> >
> > Recommended procedures are
> > >> * to copy the charmm36.ff directory into your working directory and
> > modify
> > >> ffbonded.itp to work like you want it to, or
> > >> * to give explicit parameters in the [dihedrals] section of your
> > >> molecule.itp (*not* [dihedraltypes]), so that the parameter lookup from
> > >> [dihedraltypes] is not invoked at all. Note that the behaviour for
> > >> multiple
> > >> matching [dihedrals] is to add the functions; the behaviour for multiple
> > >> matching [dihedraltypes] is to override earlier functions (except for
> > type
> > >> 9).
> > >>
> > > I'll try your second procedure and I'll let you know.
> > >
> >
> > I'd guess that's not worth your time, given that you more-or-less have the
> > first solution already done.
> >
> >
> > > Thanks for the explanation between [dihedrals] and [dihedraltypes], I
> > > didn't know about it.
> > >
> >
> > Diligent Googling will find me learning that one from Berk about 5 years
> > ago, too ;-)
> >
> > Mark
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Thu, 9 Jan 2014 23:09:27 +0530
> > From: M S <18crown10 at gmail.com>
> > To: gromacs.org_gmx-users at maillist.sys.kth.se
> > Subject: [gmx-users] RDF of Zn_water system using VMD/g_rdf
> > Message-ID:
> > <
> > CABmM0FjKXbUuE14aMA7QyPfFr66wv_xVeRfDMgp4SbtFW16jkA at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Dear friends
> >
> > A production run of 2 ns was performed for Zn2+-water system.
> > Now I wanted to generate RDF of (Zn-O) and MSD of Zn ion in water.
> > I followed two methods
> > 1. First using
> > trjconv -f traj.trr -o trajout.gro
> > then opening in vmd and got excellent g(r) for Zn-O with running
> > integration number, n(r).
> > But failed to generate using g_rdf command
> > make_ndx -f traj.trr -s topol.tpr -o index.ndx
> > here i am selecting the whole system as group
> > then
> > g_rdf -n index -o rdf.xvg
> > when it is asking for reference group and 1 more group
> > I am selecting ZN and SOL
> > but when plotting using xmgrace i am geeting multiple peak , one before
> > r_minimum.
> > Puzzling thing is that using same traj.trr, beautiful g(r) for Zn-O was
> > predicted.
> > It will be appreciated if someone catch the fault.
> >
> > second problem (same run for 2 ns)
> > g_msd -f traj.trr -s topol.tpr -o msd.xvg
> > when it is asking for the group selection
> > I am giving ZN
> > but the msd.xvg is found to be noisy and non linear if i read it using
> > xmgrace.
> > Should I have to run the simulation for time than 2 ns. The system size is
> > only 1 ZN and 215 water molecules.
> > Thanks in advance
> >
> > MALI
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Thu, 9 Jan 2014 23:37:36 +0530
> > From: abhijit Kayal <abhijitchemiitd at gmail.com>
> > To: gmx-users at gromacs.org
> > Subject: Re: [gmx-users] RDF of Zn_water system using VMD/g_rdf
> > Message-ID:
> > <CANu9SWg6Njczk8iJXbC96D=
> > wZbSoPyPQUSOZiDtdxh6yj_RTtA at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > in g_rdf command you are selecting Zn vs SOL. You first make an index file
> > for only water O atom. Then run g_rdf command and select group O. regarding
> > your second part I am not sure. Can you post the picture of msd? It will be
> > helpful what is going on.
> >
> >
> > On Thu, Jan 9, 2014 at 11:09 PM, M S <18crown10 at gmail.com> wrote:
> >
> > > Dear friends
> > >
> > > A production run of 2 ns was performed for Zn2+-water system.
> > > Now I wanted to generate RDF of (Zn-O) and MSD of Zn ion in water.
> > > I followed two methods
> > > 1. First using
> > > trjconv -f traj.trr -o trajout.gro
> > > then opening in vmd and got excellent g(r) for Zn-O with running
> > > integration number, n(r).
> > > But failed to generate using g_rdf command
> > > make_ndx -f traj.trr -s topol.tpr -o index.ndx
> > > here i am selecting the whole system as group
> > > then
> > > g_rdf -n index -o rdf.xvg
> > > when it is asking for reference group and 1 more group
> > > I am selecting ZN and SOL
> > > but when plotting using xmgrace i am geeting multiple peak , one before
> > > r_minimum.
> > > Puzzling thing is that using same traj.trr, beautiful g(r) for Zn-O was
> > > predicted.
> > > It will be appreciated if someone catch the fault.
> > >
> > > second problem (same run for 2 ns)
> > > g_msd -f traj.trr -s topol.tpr -o msd.xvg
> > > when it is asking for the group selection
> > > I am giving ZN
> > > but the msd.xvg is found to be noisy and non linear if i read it using
> > > xmgrace.
> > > Should I have to run the simulation for time than 2 ns. The system size
> > is
> > > only 1 ZN and 215 water molecules.
> > > Thanks in advance
> > >
> > > MALI
> > > --
> > > 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.
> > >
> >
> >
> >
> > --
> > Abhijit kayal
> > Research Scholar
> > Theoretical Chemistry
> > IIT Kanpur
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Thu, 09 Jan 2014 19:15:06 +0100
> > From: hubert santuz <hubert.santuz at gmail.com>
> > To: gromacs.org_gmx-users at maillist.sys.kth.se
> > Subject: Re: [gmx-users] Overriding Wildcard dihedraltypes
> > Message-ID: <52CEE72A.2010105 at gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > I tried your second procedure and it works as well.
> > I prefer this one, it's a more movable way ;)
> >
> > Le 09/01/2014 18:29, Mark Abraham a ?crit :
> > > On Thu, Jan 9, 2014 at 5:51 PM, hubert santuz <hubert.santuz at gmail.com
> > >wrote:
> > >
> > >> Hi,
> > >>
> > >> First, thanks for your detailed response.
> > >>
> > >> Thanks for the question, and particularly the detail. It seems that
> > you
> > >>> are
> > >>> trying use a [dihedraltypes] section in my_molecule.itp, which is
> > >>> generally
> > >>> a bad idea, because all such directives must appear before the first
> > >>> [molecule] directive, which defeats the point of molecule.itp files
> > being
> > >>> somewhat movable. Because of that intention for molecule.itp files,
> > >>> there'd
> > >>> be no reason to have separate [dihedraltypes] sections that should be
> > >>> logically treated together, so the code assumes such sections are
> > >>> separable, and so you get unintended behaviour (perhaps particularly
> > with
> > >>> wildcard atom types, and/or type 9 dihedrals) unless you change
> > >>> ffbonded.itp like you have now done.
> > >>>
> > >> By trying to simplify my problem, I have misleading you.
> > >> In fact, I have 2 itp files for my molecule (its is the cholesterol) :
> > >> - One containing all the *types sections [atomtypes, bondtypes,
> > >> dihedraltypes] (params_chol.itp)
> > >> - The second one is a 'regular' itp file containing [molecules, atoms,
> > >> bond ] sections. (cholesterol.itp)
> > >> So, in my topol. top, I have in reality this :
> > >>
> > >> #include "charmm36.ff/forcefield.itp"
> > >> #include "params_chol.itp"
> > >> #include "cholesterol.itp"
> > >>
> > >> My [dihedraltypes] directive is then before the [molecule] directive.
> > >> I have to do this because I have 2 new atoms for this molecule so I need
> > >> to declare them somewhere. Therefore, I also need to declare the
> > bondtypes,
> > >> angletypes and dihedraltypes associated with these 2 new atoms.
> > >> All is working well except this dihedral override.
> > >> That's why I suspected a bug but maybe it is that part I'm not doing in
> > >> the good way...
> > >
> > > Yes, the above is more workable, but it has the same problem that
> > > cholesterol.itp depends on correctly formed [dihedraltypes]. I think it
> > is
> > > likely that the implementation assumes you would not try to declare a set
> > > of additive [dihedraltypes] in such a modular way, since the
> > > copy-and-modify-ffbonded.itp procedure is available. Not ideal, but odds
> > > are excellent it won't be fixed, either ;-)
> > Yes I understand but overriding an explicit dihedraltypes is working ;)
> > But anyway, I found a solution.
> >
> > Thanks for your detailed explanations.
> >
> > Hubert
> >
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Thu, 09 Jan 2014 22:50:59 +0100
> > From: David van der Spoel <spoel at xray.bmc.uu.se>
> > To: gmx-users at gromacs.org
> > Subject: Re: [gmx-users] g_anaeig, entropy
> > Message-ID: <52CF19C3.5080609 at xray.bmc.uu.se>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > On 2014-01-08 17:25, Yulian wrote:
> > > Dear Gromacs users,
> > >
> > > There is a problem with entropy calculations with g_anaeig.
> > >
> > > I try to calculate entropy using this:
> > >
> > > g_anaeig -v eigenvec.trr -entropy
> > SO if you do
> >
> > g_anaeig -v eigenvec.trr -entropy
> > or
> > g_anaeig -v `pwd`/eigenvec.trr -entropy
> > you get a different result? that seems hard to believe unless there is a
> > random number generator at work, which there shouldn't be in this case.
> >
> > If it is reproducible please post a redmine report.
> >
> > >
> > > But result (entropy value) is not the same if I just give the name of
> > file
> > > or give the whole pass to the file.
> > > The result is also different If I run this command from different work
> > > stations.
> > >
> > > I use gromacs-4.5.6.
> > >
> > > I already asked this question before but it seems that nobody knew how to
> > > deal with it. Or maybe I miss something in previous discussions?
> > > Should I consider this effect as a gromacs bag?
> > >
> > > Thank you for any help
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > http://gromacs.5086.x6.nabble.com/g-anaeig-entropy-tp5013649.html
> > > Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
> > >
> >
> >
> > --
> > David van der Spoel, Ph.D., Professor of Biology
> > Dept. of Cell & Molec. Biol., Uppsala University.
> > Box 596, 75124 Uppsala, Sweden. Phone: +46184714205.
> > spoel at xray.bmc.uu.se http://folding.bmc.uu.se
> >
> >
> > ------------------------------
> >
> > --
> > 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.
> >
> >
> > End of gromacs.org_gmx-users Digest, Vol 117, Issue 17
> > ******************************************************
> >
> --
> 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.
More information about the gromacs.org_gmx-users
mailing list