[gmx-users] gmx gangle in the development version of gromacs

[Teemu Murtola]

On Thu, Mar 6, 2014 at 1:48 AM, Eric Smoll <ericsmoll at gmail.com> wrote:

> > As you have noted, whole_res_cog computes the center-of-geometry of the
> > whole residue that contains an individual atom. So if each of your rings
> is
> > within a single residue, this makes then selected as a unit, based on the
> > center of the whole residue. If you only want to select based on the
> center
> > of the ring, you can use part_res_cog. The difference is explained in
> 'gmx
> > help selections positions' (accessible also when writing "help" in the
> > interactive selection prompt).
>
> I will try part_res_cog but I suspect it is not what I want. 'gmx help
> selections positions'
> states:
> "part_ prefix calculates the centers for the selected atoms, but uses
> always the same atoms
> for the same residue/molecule. The used atoms are determined from the the
> largest group allowed by the selection."
> This first sentence sounds like it may preform the selection I desire but
> the second
> sentence is worrisome.  I have a molecule with a ring. My index file
> selects three atoms from this molecule to monitor - three atoms are needed
> for an normal
> vector calculation. If a cog is in the selection region but only one of the
> three atoms that
> define a given cog are in the selection region, will 'part_res_cog' result
> in the selection of all three atoms?
>

Yes, it will. If you have a selection like
  name A B C and z > 0
and your residue has atoms A B C D E, then

   - -selrtype whole_res_cog will select either all or none of A-C, based
   on the CoG of A-E.
   - -selrtype part_res_cog will select either all or none of A-C, based on
   the CoG of A-C.
   - -selrtype dyn_res_cog will in this case do the same as part_res_cog.
   It requires quite a complex selection to make a difference between the two
   (for example, "name A B C and atom z > 0 and dyn_res_cog x > 0", in which
   case the second "x > 0" condition only compares based on the CoG of the
   atoms that satisfy "z > 0"). This is probably confusing and not usually
   necessary; it mostly makes sense as an output option from the selections
   only: "dyn_res_cog of name A B C and z > 0" computes the output position
   from those atoms that actually satisfy the z > 0 condition.

If the residue index controls which atoms are grouped in a given 'residue',
> what
> controls the molecule specification?  What is it in the .gro file that
> defines an
> atom as belonging to a specific molecule?
>

There is nothing in a .gro file that specifies a molecule. This option only
works with a full .tpr file, in which case the molecule definitions from
the simulation topology are used.

This sounds like a very straightforward solution! I read up on the format
> of the
> .gro file.  It makes sense that I should be free to manipulate the residue
> numbers
> but are they any restrictions? For example. do the residue numbers need to
> be grouped and
> consecutive? I ask because a separate software (VMD) will not support
> residue number reassignment
> of various nonconsecutive atoms without disrupting the residue selection
> algorithm.
>

In Gromacs, a group of consecutive atoms with the same residue number is
treated as a single residue. If the same residue number repeats elsewhere,
then it is a different residue. There is no requirement on the numbers of
different residues being consecutive. So the atoms in a residue need to be
grouped together, but there are no other restrictions. Depending on what
you want to do with the numbers, it can be confusing, though, if the same
number repeats.

Teemu