[gmx-users] Converting between cartesian coordinates and torsion angles

[Mark Abraham]

On 15/11/2010 4:13 AM, Martin Kamp Jensen wrote:
> Hi Mark,
>
> Thanks (again, again) for your input!
>
> On Fri, Nov 12, 2010 at 5:35 PM, Mark Abraham <Mark.Abraham at anu.edu.au 
> <mailto:Mark.Abraham at anu.edu.au>> wrote:
>
>     On 13/11/2010 12:49 AM, Martin Kamp Jensen wrote:
>>     Hi,
>>
>>     As far as I understand, a topology (a .top file) and a
>>     conformation (e.g., a .gro file) contain enough information to
>>     calculate the torsion angles of that specific conformation.
>>
>>     Table 5.5 (page 124) in the GROMACS manual[1] describes possible
>>     interactions (which are contained in the topology) between
>>     different molecules while the conformation contains the cartesian
>>     coordinates. I did not immediately find a way to convert between
>>     the cartesian coordinates and the torsion angles. Can GROMACS do
>>     it or do I need to understand (or just find) all the
>>     functions/formulas that are referenced in Table 5.5?
>
>     Section 4.2 has the relevant definitions. Table 5.5 pertains to
>     the definition of force field elements that act upon (for example)
>     such internal coordinates, which is not what you're looking for.
>
>
>>
>>     I have included screenshots of Table 5.5[2] and the relevant part
>>     of some example .top file[3].
>>
>>     (Also, it seems that I can use the read_tpx method defined in
>>     include/tpxio.h to read in a topology from a .tpr file. This
>>     would then, after converting the cartesian coordinates of some
>>     conformation, enable me to work with the torsion angles in my own
>>     program before writing cartesian coordinates back for use with
>>     GROMACS.)
>
>     Either
>
>     a) write something that post-processes the result of grompp -pp in
>     concert with the same coordinate file to get the internal
>     coordinates, or
>
>
> Okay, I see that grompp -pp generates a .top file with a lot of 
> parameters (and maybe even some angles), but for some reason atom 
> numbers have been exchanged with atom names, but of course I can 
> change that back. Then I would need to apply the math from Section 4.2 
> together with a specific conformation to get the angles (and then do 
> the math to get back to cartesian coordinates after having played with 
> the angles... hmm). Unless my contacts tell me that only a few of 
> those interactions will be needed for our purposes, this seems to be 
> unnecessary extra work.
>
>
>
>     b) use a hacked version of mdrun that writes internal coordinates
>     from within src/gmxlib/bondfree.c (probably used as mdrun -rerun)
>
>
> This could be fine since I will only need to go from cartesian 
> coordinates to angles once. However, I will need to go from angles to 
> cartesian coordinates many, many times. And I would need to write 
> "inverse methods" since the methods in bondfree.c calculate angles 
> from cartesian coordinates to use them for force and energy calculations.

It seems to me that a better way of thinking/describing about what you 
want to do is to convert something to an internal coordinate 
representation, then do some operations on that, and then rebuild the 
Cartesian coordinates for GROMACS. All of that is best done by pretty 
much anything you can think of, rather than GROMACS (not least because 
you may have to rebuild the solvent and whatever else goes along with 
the changed internal coordinates). There is a body of literature and 
software that deals with this problem, which is of interest to many 
areas of computational chemistry (e.g. 
http://onlinelibrary.wiley.com/doi/10.1002/jcc.20237/abstract, and many 
Google hits).

> Or am I missing something - is it possible to let GROMACS work on 
> angles instead of cartesian coordinates? (I mean give the input not 
> as, e.g., a .gro file with cartesian coordinates, but as another file 
> with torsion angles - which I will first get via bondfree.c.)

No, GROMACS will only accept Cartesian input. While it is well known 
that geometry optimization is best done in (redundant) internal 
coordinates when the evaluation of energy and/or force is expensive 
(e.g. quantum chemistry on small systems), this is not true for the 
large majority of EM problems on biomolecular systems. There, the 
problem is dominated by the presence of multiple minima, the result is 
not of great interest if you're preparing a system for MD, and there is 
no payoff for the development time. Thus, GROMACS only computes an 
internal coordinate immediately before using it to evaluate its 
contribution to bonded energy and/or force, and then discards it.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20101115/8066ec93/attachment.html>