[gmx-users] g_density -center issues (GMX version 4.6)

[Reid Van Lehn]

Hi users/developers,

I identified 2 issues in the center_coords function of g_density that make
the flag -center incorrectly center the system. These are in addition to
the issues previously raised by Chris Neale (reported as issue 1168 on
redmine: http://redmine.gromacs.org/issues/1168). I have added these two
issues to the same redmine bug report as they are related to the same
analysis tool/similar issues; following from Chris' previous advice, I also
suggest that users not use the -center flag and instead center their
trajectories prior to running g_density using trjconv. The issues described
below are present in g_density for GMX 4.6 and presumably for earlier/later
versions as well; I apologize if these have been updated in 4.6.1 or 4.6.2.

The function center_coords is intended to shift the COM of the system to
bX/2, bY/2, 0 as described in the help documentation for bCenter. This is
accomplished by calculating a shift vector on line 153 (line numbers may be
off, sorry):

rvec_sub(box_center, com, shift);

and then subtracting the shift from all coordinates in a loop on line 162:

for (i = 0; (i < atoms->nr); i++)
   rvec_dec(x0[i], shift);

This is incorrect; the shift vector should be added to all coordinates, not
subtracted, for the COM to be centered since rvec_sub sets shift to
box_center - com. This can be fixed by changing rvec_dec to rvec_inc, which
I have verified returns the correctly centered coordinates.

The other issue is that the COM is computed by weighting by the mass of
each atom obtained from the topology, as shown in the command:

mm = atoms->atom[i].m;

This is fine if the -dens flag is set to mass or electron; but for number
or charge the atom[i].m variable in the topology is reset in the function
g_density to either 1 (for -dens number) or the atom's charge (for -dens
charge). The system is thus centered not by the center of mass, but rather
by the geometric center/center of charge respectively. This could be fine
but may not be obvious to the user.

Again I added a report of both issues to the redmine report and wanted to
inform users of their existence in case this affects the use of the
g_density tool.

Best,
Reid
-- 
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Removing Water from Final Simulation

[Reid Van Lehn]

FYI you can also take the complement of an existing group with make_ndx
using the ! symbol.

e.g. if water is group 0, you could make a group of everything but water
using:

!0

This might be easier/more foolproof than concatenating all other groups
when generating the appropriate index file as suggested in the previous
email.

Best,
- Reid


On Sun, Jun 2, 2013 at 10:40 PM, Dallas Warren wrote:

> What group did you select from the list offered when you ran the script?
>  Did it include all of your molecules, minus water?  Or did you just select
> something like "Protein"?
>
> You need to run make_ndx and general a group that contains all of the
> molecules you want.  So you will want to do something like "1 | 2 | 3" when
> running make_ndx  What those numbers are depends on what is contained
> within the gro file you feed it.
>
> Catch ya,
>
> Dr. Dallas Warren
> Drug Discovery Biology
> Monash Institute of Pharmaceutical Sciences, Monash University
> 381 Royal Parade, Parkville VIC 3052
> dallas.war...@monash.edu
> +61 3 9903 9304
> -
> When the only tool you own is a hammer, every problem begins to resemble a
> nail.
>
>
> > -Original Message-
> > From: gmx-users-boun...@gromacs.org [mailto:gmx-users-
> > boun...@gromacs.org] On Behalf Of Parker de Waal
> > Sent: Monday, 3 June 2013 11:53 AM
> > To: Discussion list for GROMACS users
> > Subject: Re: [gmx-users] Removing Water from Final Simulation
> >
> > Thanks Warren for your help, those were exactly the functions I was
> > looking
> > for!
> >
> > However I'm still experiencing a bit of trouble because my simulated
> > protein contained a heme cofactor and it seems to only let me extract
> > one
> > object.
> >
> > Have you had any experience with this?
> >
> > Parker
> > On Sun, Jun 2, 2013 at 9:47 PM, Dallas Warren
> > wrote:
> >
> > > trjconv for trajectories
> > > editconf for coordinate files
> > >
> > > Along with an appropriately generated index file (using make_ndx)
> > which
> > > contains the molecules you want in the output within a single group.
> > >
> > > Catch ya,
> > >
> > > Dr. Dallas Warren
> > > Drug Discovery Biology
> > > Monash Institute of Pharmaceutical Sciences, Monash University
> > > 381 Royal Parade, Parkville VIC 3052
> > > dallas.war...@monash.edu
> > > +61 3 9903 9304
> > > -
> > > When the only tool you own is a hammer, every problem begins to
> > resemble a
> > > nail.
> > >
> > >
> > > > -Original Message-
> > > > From: gmx-users-boun...@gromacs.org [mailto:gmx-users-
> > > > boun...@gromacs.org] On Behalf Of Parker de Waal
> > > > Sent: Monday, 3 June 2013 11:10 AM
> > > > To: gmx-users@gromacs.org
> > > > Subject: [gmx-users] Removing Water from Final Simulation
> > > >
> > > > Hi GMX users!
> > > >
> > > > I just completed my first 30 ns simulation and would to remove all
> > > > water
> > > > molecules from the resulting .gro and trajectory files for the sake
> > of
> > > > my
> > > > HDD.
> > > >
> > > > Does anyone know how to do this?
> > > >
> > > > Cheers,
> > > > Parker
> > > > --
> > > > gmx-users mailing listgmx-users@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-requ...@gromacs.org.
> > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > > --
> > > gmx-users mailing listgmx-users@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-requ...@gromacs.org.
> > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> > --
> > gmx-users mailing listgmx-users@gromacs.org
> > http://lists.gromacs.org/mailman/listinfo/gmx-users
> > * Please 

Re: [gmx-users] mdrun outputs incorrect resnames

[Reid Van Lehn]

Great, thank you that did the trick. My fault for not realizing this
earlier.

Best,
Reid


On Sun, May 26, 2013 at 2:12 AM, Tsjerk Wassenaar  wrote:

> No, the residue names are the those from the .top file. But that's not the
> same as the moleculetypes. You have to change the residue names in the [
> atoms ] section.
>
> Cheers,
>
> Tsjerk
>
>
> On Sun, May 26, 2013 at 12:57 AM, Mark Abraham  >wrote:
>
> > AFAIK, the residue names in the mdrun output .gro file are those of the
> > structure file you gave to grompp.
> >
> > Mark
> >
> >
> > On Sun, May 26, 2013 at 12:31 AM, Reid Van Lehn 
> > wrote:
> >
> > > Hello,
> > >
> > > I am simulating a lipid bilayer and wish to apply position restraints
> to
> > > only a subset of the lipids in the bilayer. Since position restraints
> are
> > > applied to all molecules of the same molecule type, I defined a new
> > > molecule type (DOPR) which is identical to my lipid species (DOPC) by
> > > copying the lipid itp file, renaming it and renaming the corresponding
> > > molecule type. I then manually edited a starting .gro file to change a
> > > subset of the DOPC molecules to DOPR, edited my topology,
> > > renumbered/reordered, etc. I also recreated the index file to account
> for
> > > the new molecules so that temperature coupling could be used correctly.
> > >
> > > Everything seemed ok when I ran the mdrun - grompp didn't complain, the
> > > program ran normally, the output trajectory clearly used the correct
> > > position restraints, etc. The weird part, though, is that the output
> .gro
> > > file at the end of the simulation only had DOPC molecules in it - the
> > DOPR
> > > molecules that I had renamed by hand had somehow been output as DOPC
> > > instead. Positions, number of atoms, everything else was fine, just the
> > > name of the residues was different. I can't figure out why this is
> > > happening. It was reproducible across both GMX 4.5.5 / 4.6 and multiple
> > > different starting files.
> > >
> > > It's not a huge issue since the trajectories themselves are fine, I'm
> > just
> > > worried this issue might indicate other, less obvious problems. A
> snippet
> > > of the topol file is below if that is helpful.
> > >
> > > Any suggestions / advice would be appreciated!
> > >
> > > 
> > > #include "forcefield.itp
> > > #include "dopc.itp"
> > >
> > > #ifdef POSRES
> > > #include "dopc-posre.itp"
> > > #endif
> > >
> > > ; Always include DOPR restraints for restrained lipids
> > > #include "dopc_restrained.itp"
> > > #include "dopr-posre.itp"
> > >
> > > #include "spc.itp"
> > > #include "ions.itp"
> > >
> > > [ system ]
> > > ; Name
> > > frame t= 1.000 in water
> > >
> > > [ molecules ]
> > > ; Compound#mols
> > > DOPC 398
> > > DOPR   2
> > > SOL63882
> > > NA   179
> > > CL   179
> > > *
> > >
> > > Thanks,
> > > Reid
> > > --
> > > gmx-users mailing listgmx-users@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-requ...@gromacs.org.
> > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> > --
> > gmx-users mailing listgmx-users@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-requ...@gromacs.org.
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
>
>
>
> --
> Tsjerk A. Wassenaar, Ph.D.
> --
> gmx-users mailing listgmx-users@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-requ...@gromacs.org.
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>



-- 
Reid Van Lehn
NSF/MIT Presidential Fellow
Alfredo Alexander-Katz Research Group
Ph.D Candidate - Materials Science
-- 
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] mdrun outputs incorrect resnames

[Reid Van Lehn]

Hello,

I am simulating a lipid bilayer and wish to apply position restraints to
only a subset of the lipids in the bilayer. Since position restraints are
applied to all molecules of the same molecule type, I defined a new
molecule type (DOPR) which is identical to my lipid species (DOPC) by
copying the lipid itp file, renaming it and renaming the corresponding
molecule type. I then manually edited a starting .gro file to change a
subset of the DOPC molecules to DOPR, edited my topology,
renumbered/reordered, etc. I also recreated the index file to account for
the new molecules so that temperature coupling could be used correctly.

Everything seemed ok when I ran the mdrun - grompp didn't complain, the
program ran normally, the output trajectory clearly used the correct
position restraints, etc. The weird part, though, is that the output .gro
file at the end of the simulation only had DOPC molecules in it - the DOPR
molecules that I had renamed by hand had somehow been output as DOPC
instead. Positions, number of atoms, everything else was fine, just the
name of the residues was different. I can't figure out why this is
happening. It was reproducible across both GMX 4.5.5 / 4.6 and multiple
different starting files.

It's not a huge issue since the trajectories themselves are fine, I'm just
worried this issue might indicate other, less obvious problems. A snippet
of the topol file is below if that is helpful.

Any suggestions / advice would be appreciated!


#include "forcefield.itp
#include "dopc.itp"

#ifdef POSRES
#include "dopc-posre.itp"
#endif

; Always include DOPR restraints for restrained lipids
#include "dopc_restrained.itp"
#include "dopr-posre.itp"

#include "spc.itp"
#include "ions.itp"

[ system ]
; Name
frame t= 1.000 in water

[ molecules ]
; Compound#mols
DOPC 398
DOPR   2
SOL63882
NA   179
CL   179
*

Thanks,
Reid
-- 
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] where is gromos54a7_lipid FF?

[Reid Van Lehn]

It's available in Gromacs format from the Automatic Topology Builder
website:

http://compbio.biosci.uq.edu.au/atb/index.py?tab=forceField_tab


On Sat, Apr 6, 2013 at 6:38 AM, Albert  wrote:

> Hello:
>
>  I saw lots of people is using gromos54a7_lipid FF and I search the
> gromacs webiste, but didn't find it. Would anybody tell me where can we
> obtain it?
>
> THX
>
> Albert
> --
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/**mailman/listinfo/gmx-users<http://lists.gromacs.org/mailman/listinfo/gmx-users>
> * Please search the archive at http://www.gromacs.org/**
> Support/Mailing_Lists/Search<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-requ...@gromacs.org.
> * Can't post? Read 
> http://www.gromacs.org/**Support/Mailing_Lists<http://www.gromacs.org/Support/Mailing_Lists>
>



-- 
Reid Van Lehn
NSF/MIT Presidential Fellow
Alfredo Alexander-Katz Research Group
Ph.D Candidate - Materials Science
-- 
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Thread affinity setting failed

[Reid Van Lehn]

Hi Szilárd,

Thank you very much for the detailed write up. To answer your question,
yes, I am using an old Linux distro, specifically CentOS 5.4, though
upgrading to 5.9 still had the same problem. I have another few machines
with different hardware CentOS 6.3 which does not have this issue so it is
likely an operating system issue based on your description. As I'm
(unfortunately...) also the sysadmin on this cluster I'm unlikely to find
the time to upgrade all the nodes, so I'll probably stick with the "-pin
off" workaround for now. Hopefully this thread might help out other users!

As an aside, I found that the OpenMP + Verlet combination was slower for
this particular system, but I suspect that it's because it's almost
entirely water and hence probably benefits from the Group scheme
optimizations for water described on the Gromacs website.

Thanks again for the explanation,
Reid

On Mon, Mar 4, 2013 at 3:45 PM, Szilárd Páll  wrote:

> Hi,
>
> There are some clarifications needed and as this might help you and other
> understand what's going on, I'll take the time to explain things.
>
> Affinity setting is a low-, operating system-level, operation and "locks"
> (="pins") threads to physical cores of the CPU preventing the OS from
> moving them which can cause performance drop - especially when using
> OpenMP-multithreading on multi-socket and NUMA machines.
>
> Now, mdrun will by default *try* to set affinity if you use all cores
> detected (i.e if mdrun can be sure that it is the only application running
> on the machine), but will by default *not* set thread affinities if the
> number of thread/processes per compute node is less than the number of
> cores detected. Hence, when you decrease -ntmpi to 7, you implicitly end up
> turning off thread pinning, that's why the warnings don't show up.
>
> The fact that affinity setting fails on your machine suggests that either
> the system libraries don't support this or the mdrun code is not fully
> compatible with your OS, the type of CPUs AFAIK don't matter at all. What
> OS are you using? Is it an old installation?
>
> If you are not using OpenMP - which btw you probably should with the Verlet
> scheme if you are running running on a single node or at high
> parallelization -, the performance will not be affected very much by the
> lack of thread pinning. While the warnings themselves can often be safely
> ignored, if only some of the threads/processes can't set affinities, this
> might indicate a problem. I your case, if you were really seeing only 5
> cores being used with 3 warnings, this might suggest that while the
> affinity setting failed, three threads are using already "busy" cores
> overlapping with others which will cause severe performance drop.
>
> What you can do to avoid the performance drop is to turn of pinning by
> passing "-pin off" to mdrun. Without OpenMP this will typically not cause a
> large performance drop compared to having correct pinning and it will avoid
> the bad overlapping threads/processes case.
>
> I suspect that your machines might be running an old OS which could be
> causing the failed affinity setting. If that is the case, you should talk
> to your sysadmins and have them figure out the issue. If you have a
> moderately new OS, you should not be seeing such issues, so I suggest that
> you file a bug report with details like: OS + version + kernel version,
> pthread library version, standard C library version.
>
> Cheers,
>
> --
> Szilárd
>
>
> On Mon, Mar 4, 2013 at 1:45 PM, Mark Abraham  >wrote:
>
> > On Mon, Mar 4, 2013 at 6:02 AM, Reid Van Lehn  wrote:
> >
> > > Hello users,
> > >
> > > I ran into a bug I do not understand today upon upgrading from v. 4.5.5
> > to
> > > v 4.6. I'm using older 8 core Intel Xeon E5430 machines, and when I
> > > submitted a job for 8 cores to one of the nodes I received the
> following
> > > error:
> > >
> > > NOTE: In thread-MPI thread #3: Affinity setting failed.
> > >   This can cause performance degradation!
> > >
> > > NOTE: In thread-MPI thread #2: Affinity setting failed.
> > >   This can cause performance degradation!
> > >
> > > NOTE: In thread-MPI thread #1: Affinity setting failed.
> > >   This can cause performance degradation!
> > >
> > > I ran mdrun simply with the flags:
> > >
> > > mdrun -v -ntmpi 8 -deffnm em
> > >
> > > Using the top command, I confirmed that no other programs were running
> > and
> > > that mdrun was in fact only using 5 cores. Reducing -ntm

[gmx-users] Thread affinity setting failed

[Reid Van Lehn]

Hello users,

I ran into a bug I do not understand today upon upgrading from v. 4.5.5 to
v 4.6. I'm using older 8 core Intel Xeon E5430 machines, and when I
submitted a job for 8 cores to one of the nodes I received the following
error:

NOTE: In thread-MPI thread #3: Affinity setting failed.
  This can cause performance degradation!

NOTE: In thread-MPI thread #2: Affinity setting failed.
  This can cause performance degradation!

NOTE: In thread-MPI thread #1: Affinity setting failed.
  This can cause performance degradation!

I ran mdrun simply with the flags:

mdrun -v -ntmpi 8 -deffnm em

Using the top command, I confirmed that no other programs were running and
that mdrun was in fact only using 5 cores. Reducing -ntmpi to 7, however,
resulted in no error (only a warning about not using all of the logical
cores) and mdrun used 7 cores correctly. Since it warned about thread
affinity settings, I tried setting -pin on -pinoffset 0 even though I was
using all the cores on the machine. This resulted in the same error.
However, turning pinning off explicitly with -pin off (rather than -pin
auto) did correctly give me the all 8 cores again.

While I figured out a solution in this particular instance, my question is
whether I should be have known from my hardware/settings that pinning
should be turned off (for future reference), or if this is a bug?

Thanks!
Reid
-- 
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Re: Extracting the timestep value from topology and/or trajectory files

[Reid Van Lehn]

Check gmx_energy.c. It contains this line:

read_tpx(topnm, &ir, box, &natoms, NULL,NULL, NULL, &mtop);

where ir is t_inputrec.

Reid

On Thu, Feb 21, 2013 at 1:48 PM, shavit  wrote:

> I think your'e right.  I'm currently trying to make it work, but am not
> really succeeding.  I'm declaring t_inputrec *ir, and then trying to
> reference ir->delta_t.  Even in compile-time, I get a warning that delta_t
> is being used without being initialized, which makes sense.  Is there any
> function that is called in the standard gromacs template that initializes
> and sets delta_t to the timestep size?
>
> My apologies if this is a beginner's question, and thank you so much for
> your help,
>
> Amit
>
>
> On Thu, Feb 21, 2013 at 1:11 PM, Justin Lemkul [via GROMACS] <
> ml-node+s5086n5005770...@n6.nabble.com> wrote:
>
> >
> >
> > On 2/21/13 9:47 AM, shavit wrote:
> >
> > > Hello,
> > >
> > > For several months now, I've been writing my own analysis tools using
> > the
> > > GROMACS template.c file.  There is one thing I haven't been able to
> > figure
> > > out, and that is how to get the timestep size.
> > >
> > > I'm confident this parameter is located in either the traj.trr file or
> > the
> > > topol.tpr that I feed into all of my analysis codes, I just can't
> figure
> > out
> > > how to access it.
> > >
> >
> > If memory serves, the t_inputrec structure holds it in ir->delta_t.
> >
> > -Justin
> >
> > --
> > 
> >
> > Justin A. Lemkul, Ph.D.
> > Research Scientist
> > Department of Biochemistry
> > Virginia Tech
> > Blacksburg, VA
> > jalemkul[at]vt.edu | (540) 231-9080
> > http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
> >
> > 
> > --
> > gmx-users mailing list[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5005770&i=0>
> > 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 [hidden email]<
> http://user/SendEmail.jtp?type=node&node=5005770&i=1>.
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> >
> > --
> >  If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://gromacs.5086.n6.nabble.com/Extracting-the-timestep-value-from-topology-and-or-trajectory-files-tp5005760p5005770.html
> >  To unsubscribe from Extracting the timestep value from topology and/or
> > trajectory files, click here<
> http://gromacs.5086.n6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5005760&code=c2hhdml0QHNlYXMudXBlbm4uZWR1fDUwMDU3NjB8LTE1Mjg1MDQ5MTk=
> >
> > .
> > NAML<
> http://gromacs.5086.n6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://gromacs.5086.n6.nabble.com/Extracting-the-timestep-value-from-topology-and-or-trajectory-files-tp5005760p5005772.html
> Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
> --
> gmx-users mailing listgmx-users@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-requ...@gromacs.org.
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>



-- 
Reid Van Lehn
NSF/MIT Presidential Fellow
Alfredo Alexander-Katz Research Group
Ph.D Candidate - Materials Science
--
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Re: Water models and diffusion coefficient

[Reid Van Lehn]

What time period do you use to fit the mean-squared displacement to
determine the diffusion coefficient? g_msd determines the diffusion
coefficient by performing a linear fit over the time interval specified by
the -beginfit and -endfit flags, which default to 10% and 90% of the
simulation time (if I remember correctly) if you do not specify values. If
your mean-squared displacement is not linear over this interval, then you
could have a very poor estimate of the diffusion coefficient. You might to
look at the plots of the MSD generated to see if it is linear over the
interval you fit; if it plateaus over this period then likely the diffusion
coefficient is an underestimate, and since the value you measure is
relatively close to the literature value then that could explain the lower
value.

- Reid


On Sat, Feb 9, 2013 at 9:12 AM, learnmd  wrote:

> Thanks for your reply David. However, what I am concerned is that with the
> parameters, q[O] = -0.870, and q[H] = 0.435, the original author reported
> diffusion coefficient very close to 2.0 e-5 cm^2/s. My values for even much
> longer simulations (200 ns after 1ns each of NVT and NPT equilibration)
> reports diffusion coefficients which are always much lesser ( in the range
> 1.4 - 1.5 e-5 cm^2/s).
>
> I was wondering if there is something that I should understand better about
> g_msd not getting the right mass of H atoms?
>
>
>
>
> --
> View this message in context:
> http://gromacs.5086.n6.nabble.com/Water-models-and-diffusion-coefficient-tp5005377p5005380.html
> Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
> --
> gmx-users mailing listgmx-users@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-requ...@gromacs.org.
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> --
> Reid Van Lehn
> NSF/MIT Presidential Fellow
> Alfredo Alexander-Katz Research Group
> Ph.D Candidate - Materials Science
> <http://www.gromacs.org/Support/Mailing_Lists>
>
-- 
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] gmxcheck and GROMOS96 bonds

[Reid Van Lehn]

Will do, thank you for fast response!

Reid

On Tue, Jan 8, 2013 at 11:11 AM, Justin Lemkul  wrote:

>
>
> On 1/8/13 10:56 AM, Reid Van Lehn wrote:
>
>> Hi Gromacs users,
>>
>> I was using gmxcheck to check a simple trajectory of surfactants, and get
>> many errors of the type "Distance between atoms X and Y is 0.153, should
>> be
>> 0.023" where the actual distance is always approximately correct and the
>> "correct" value is the square of the actual distance. This always occurs
>> for G96 type bonds, where I am defining the bonds using the macros in the
>> ffbonded.ff file for the gromos53a6.ff force field (e.g. gb_27 in that
>> example). A typical line from my topology is then:
>>
>> [ bonds ]
>> 3   4   2   gb_27
>> etc.
>>
>> I also noticed the same errors when using gmxcheck on the output of the
>> energy minimization in Justin Lemkul's KALP-15 tutorial, which also uses
>> GROMOS96 bonds. I did not get errors for other steps in that tutorial,
>> presumably because the bonds are constrained using LINCs.
>>
>> I am using Gromacs 4.5.5 and it appears that the relevant lines from the
>> source code in gmxcheck.c are:
>>
>> switch (ftype) {
>>  case F_BONDS:
>>  case F_G96BONDS:
>>b0 = idef->iparams[type].harmonic.**rA;
>>break;
>>  case F_MORSE:
>>b0 = idef->iparams[type].morse.b0;
>>break;
>>  case F_CUBICBONDS:
>>b0 = idef->iparams[type].cubic.b0;
>>break;
>>  case F_CONSTR:
>>b0 = idef->iparams[type].constr.dA;
>>break;
>>  default:
>>break;
>>  }
>>
>> It's not clear to me why b0 would be squared here since the switch
>> statement doesn't look to discriminate between function 1 and function 2
>> bonds (if I interpret this correctly). Do you think I have something
>> incorrectly defined in my topology, or does gmxcheck not correctly process
>> G96 bonds? Since the actual bond lengths look correct I'm not too worried
>> about it, but I want to resolve any errors if they do exist since right
>> now
>> gmxcheck cannot really be used to find actual bonding errors. I apologize
>> if this is something obvious that I missed as I am a beginner in Gromacs.
>>
>>
> This appears to be a small output bug.  There is nothing wrong with your
> topology or simulation.  Please file a bug report on redmine.gromacs.orgwith 
> all of the information above.
>
> -Justin
>
> --
> ==**==
>
> Justin A. Lemkul, Ph.D.
> Research Scientist
> Department of Biochemistry
> Virginia Tech
> Blacksburg, VA
> jalemkul[at]vt.edu | (540) 231-9080
> http://www.bevanlab.biochem.**vt.edu/Pages/Personal/justin<http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin>
>
> ==**==
> --
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/**mailman/listinfo/gmx-users<http://lists.gromacs.org/mailman/listinfo/gmx-users>
> * Please search the archive at http://www.gromacs.org/**
> Support/Mailing_Lists/Search<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-requ...@gromacs.org.
> * Can't post? Read 
> http://www.gromacs.org/**Support/Mailing_Lists<http://www.gromacs.org/Support/Mailing_Lists>
>



-- 
Reid Van Lehn
NSF/MIT Presidential Fellow
Alfredo Alexander-Katz Research Group
Ph.D Candidate - Materials Science
-- 
gmx-users mailing listgmx-users@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-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists