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.abra...@anu.edu.au <mailto:mark.abra...@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
-- 
gmx-users mailing list    gmx-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

Reply via email to