[gmx-users] gromacs.org_gmx-users Digest, Vol 117, Issue 17
M S
18crown10 at gmail.com
Fri Jan 10 05:11:39 CET 2014
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
> ******************************************************
>
More information about the gromacs.org_gmx-users
mailing list