[gmx-users] Inconsistency in units of virtual sites?

Tue Nov 21 11:30:05 CET 2017

Hoi Douwe,

according to the manual the units are indeed inconsistent (but
documented, and therefore ok). See table 5.5 of the manual. For 3out the
unit of c is in nm^-1.

Peter

On 21-11-17 10:15, Douwe Pollmann wrote:
> Thanks Justin for the reply.
>
> I'm sorry for the inconvenience, I put 1/3 in stead of 0.3333333 in this
> example for clarity, but apparently it wasn't clear at all..
> Below a part of the real .itp file is shown:
> ; The virtual sites for the side chain beads
> [ virtual_sites3 ]
> ;Site     from                   funct        a                 b
>  17       1       2       3        2      5.000000e-01      -0.000000
>  18       2       1       3        2      5.000000e-01      -0.263000
>  19       3       2       4        2      5.000000e-01      -0.358000
>  20       4       3       5        2      5.000000e-01      -0.143000
>  21       5       4       6        2      5.000000e-01      -0.336000
>  .
>  .
>  .
>
> ; The virtual sites for the O and H atoms to simulate hydrogen bonds
> [ virtual_sites3 ]
> ;Site     from                   funct       a             b          c
>  33       2       1       3        4      6.6667e-01    0.0000    -1.1000
>  34       2       1       3        4      3.3333e-01    0.0000     1.1000
>  35       3       2       4        4      6.6667e-01    0.0000     1.1000
>  36       3       2       4        4      3.3333e-01    0.0000    -1.1000
>  37       4       3       5        4      6.6667e-01    0.0000    -1.1000
>  38       4       3       5        4      3.3333e-01    0.0000     1.1000
>  .
>  .
>  .
>
>
> The distances (or actually fractions) a and b are not the problem, it is
> the value for c that is problematic.
> With these settings, I see in VMD what I want to see. So the distance of
> site 20 to the backbone is a bit larger than the distance of the O and H
> atoms to the backbone. However, when I use c = +/- 0.11 nm (which is the
> most logical option because everything should be in nm as you said), the O
> and H atoms are very close to the backbone, while the side chain beads are
> at the correct distance.
> I also checked if it is a problem that I have twice a header with [
> virtual_sites3 ], but putting everything underneath one header is not the
> solution to this problem..
>
> I excluded the interactions between opposing O/H (33 34, 35 36, etc) and
> also between the neighbouring O/H on both sides. So I think it cannot be
> the case that those atoms are pulled together by an attractive force,
> causing a factor of 10 in the distance to the bonds.
>
> Do you or someone else have another suggestion what could go wrong?
>
> Kind regards,
> Douwe
>
>
>
> 2017-11-20 17:11 GMT+01:00 Justin Lemkul <jalemkul at vt.edu>:
>
>>
>> On 11/20/17 9:50 AM, Douwe Pollmann wrote:
>>
>>> Dear all,
>>>
>>> I am doing simulations with a coarse grained model and I am using virtual
>>> sites to define the positions of the side chains (SC) and the positions of
>>> O and H atoms (HB) to include hydrogen bonding in the system.
>>> For SC I use the 3fd option and for the HB atoms I use option 3out.
>>> The 3fd option is specified by:
>>> [ virtual_sites3 ]
>>> ; Site  from   funct  a    d
>>>    n     i j k  2      0.5  -0.1
>>>
>>> and the 3out option is given by
>>>
>>> [ virtual_sites3 ]
>>> ; Site   from    funct  a     b     c
>>>    n      i j k   4      1/3   0     1
>>>
>>> 3fd makes a virtual site in the same plane as the backbone atoms (*i*, *j*
>>> and *k*) and 3out creates a virtual site pointing perpendicular to the
>>> plane made by *i*, *j* and *k*, in this case along the bond between *i*
>>> and
>>> *j*.
>>> For the exact details about virtual sites, see section 4.7 and 5.2.2 in
>>> the
>>> manual: http://manual.gromacs.org/documentation/5.1.4/manual-5.1.4.pdf .
>>>
>>> For both options you have to specify a distance from site *n* to the
>>> backbone (*d* and *c *respectively).
>>> However, in the case I want to have the distance SC-backbone the same as
>>> HB-backbone, the value for *c* needs needs to be 10 times bigger than *d*.
>>> So it seems to me I have to give the value for *d* in nm and the value for
>>> *c* in Angstrom.
>>>
>>> In the manual I cannot find anything about the units needed for the
>>> virtual
>>> sites.
>>> So my question is:
>>> Does anyone of you know if the units for the distances in different
>>> options
>>> for virtual sites should be the same or that they are inconsistent with
>>> each other?
>>>
>> GROMACS only ever uses nm, except when doing I/O for PDB files, which are
>> in A. But the units are consistent for everything that GROMACS does. You're
>> probably getting weird behavior by trying to specify "a = 1/3" rather than
>> "a = 0.3333333"
>>
>> -Justin
>>
>> --
>> ==================================================
>>
>> Justin A. Lemkul, Ph.D.
>> Assistant Professor
>> Virginia Tech Department of Biochemistry
>>
>> 303 Engel Hall
>> 340 West Campus Dr.
>> Blacksburg, VA 24061
>>
>> jalemkul at vt.edu | (540) 231-3129
>> http://www.biochem.vt.edu/people/faculty/JustinLemkul.html
>>
>> ==================================================
>>
>> --
>> 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.
>>