[gmx-developers] free energy calculations with restraints
David Mobley
dmobley at gmail.com
Fri Mar 7 23:17:59 CET 2014
Hi, all,
I've finished my first round of testing on these restraints and submitted a
bug report with what I think are two issues.
Thanks.
On Fri, Feb 7, 2014 at 12:58 PM, David Mobley <dmobley at gmail.com> wrote:
> Hi, all,
>
> I'm working on testing this, but have run into an apparent bug in 4.6.x
> and this version unearthed by my test system (
> http://redmine.gromacs.org/issues/1433). So, I'm temporarily stalled, but
> will proceed as soon as it's resolved.
>
> Thanks!
>
>
>
> On Wed, Feb 5, 2014 at 1:15 PM, David Mobley <dmobley at gmail.com> wrote:
>
>> For the record, I am currently working on testing this functionality and
>> will update as soon as I have news.
>>
>> Thanks.
>>
>>
>>
>> On Fri, Jan 10, 2014 at 6:43 AM, Erik Lindahl <erik.lindahl at scilifelab.se
>> > wrote:
>>
>>> Hi,
>>>
>>> In practice I think it's pretty easy: We're unlikely to include this
>>> patch in Gromacs-5.0 unless somebody has volunteered and tested that it
>>> works correctly ;-)
>>>
>>> Cheers,
>>>
>>> Erik
>>>
>>>
>>>
>>> On 09 Jan 2014, at 23:11, David Mobley <dmobley at gmail.com> wrote:
>>>
>>> Hi, Mark,
>>>
>>> I do want to test this soon (it's still on my "soon" list), but
>>> realistically it will be at least next week before I can look at it. I'll
>>> have a student try and see what she can do as well.
>>>
>>> To give a bit of backdrop as to why this is involved/slow -- we use
>>> this for doing absolute binding free energy calculations. In the last 8
>>> years or so, we've basically applied these calculations in a total of four
>>> different systems. So, while we've wanted this for years (probably, 8+
>>> years!) our throughput is not very high here. Additionally, the
>>> calculations are fairly computationally demanding, so we can't just swap in
>>> a new set of restraints and have immediate feedback on whether they are
>>> working well. We have not set up any NEW absolute free energy calculations
>>> since this has been implemented, hence the delay in testing.
>>>
>>> Realistically, I can have feedback in the next couple weeks on whether
>>> it appears to have the features we need, but in terms of whether it is
>>> working properly, it would take us much longer (i.e., we would validate
>>> absolute binding free energy calculations done with these restraints,
>>> versus what we get with the "old" restraints). Perhaps someone else is able
>>> to test whether it correctly implements what is supposed to be implemented?
>>>
>>> Thanks!
>>> David
>>>
>>>
>>>
>>>
>>> On Wed, Jan 8, 2014 at 10:20 PM, Mark Abraham <mark.j.abraham at gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> Can those who were keen on this feature (David Mobley? Michael
>>>> Shirts?) for intermolecular bonded interactions please test it? It's pretty
>>>> discouraging to have people claim they've wanted something for years and
>>>> then have four months pass without feedback on whether Berk's effort does
>>>> what they really want! Please see https://gerrit.gromacs.org/#/c/2566/
>>>>
>>>> Thanks,
>>>>
>>>> Mark
>>>>
>>>>
>>>> On Mon, Sep 23, 2013 at 1:10 AM, Mark Abraham <mark.j.abraham at gmail.com
>>>> > wrote:
>>>>
>>>>> Please can those who have been keen on the feature for which Berk
>>>>> kindly wrote some code let us know whether they plan to test it some
>>>>> time soon?
>>>>>
>>>>> Mark
>>>>>
>>>>> On Sun, Sep 1, 2013 at 5:51 AM, Shirts, Michael (mrs5pt)
>>>>> <mrs5pt at eservices.virginia.edu> wrote:
>>>>> > Great, this is exactly the documentation needed to test it.
>>>>> >
>>>>> > So if one wants to use these as free energy-dependent restraining
>>>>> terms,
>>>>> > which correspond to the restraint part of the lambda vector, not the
>>>>> bonded
>>>>> > part, then one just needs to make sure that one uses the restraint
>>>>> bonded
>>>>> > types, not normal bonded types.
>>>>> >
>>>>> > I do not there are no explicit angle restraint terms for three
>>>>> atoms. Can
>>>>> > the four-atom angle_restraint be used as a three angle restraint by
>>>>> > repeating one of the pairs?
>>>>> >
>>>>> > Best,
>>>>> > ~~~~~~~~~~~~
>>>>> > Michael Shirts
>>>>> > Assistant Professor
>>>>> > Department of Chemical Engineering
>>>>> > University of Virginia
>>>>> > michael.shirts at virginia.edu
>>>>> > (434)-243-1821
>>>>> >
>>>>> >
>>>>> >> From: Berk Hess <hess at kth.se>
>>>>> >> Date: Sat, 31 Aug 2013 09:31:32 +0200
>>>>> >> To: "michael.shirts at virginia.edu" <michael.shirts at virginia.edu>,
>>>>> Discussion
>>>>> >> list for GROMACS development <gmx-developers at gromacs.org>
>>>>> >> Subject: Re: [gmx-developers] free energy calculations with
>>>>> restraints
>>>>> >>
>>>>> >> Hi,
>>>>> >>
>>>>> >> I haven't documented it yet, as I want to be sure this is the
>>>>> >> functionality people were asking for.
>>>>> >> I didn't add new interaction types, as we can reuse all the grompp
>>>>> and
>>>>> >> mdrun code and we don't need even more interaction types and
>>>>> requests
>>>>> >> for support. At the mdrun level there is no difference between the
>>>>> usual
>>>>> >> intramolecular and the new intermolecular interactions, except for
>>>>> the
>>>>> >> graph code, as that only ensure intramolecular interactions don't
>>>>> need
>>>>> >> pbc treatment.
>>>>> >> It is really simple, here is a small example .top file:
>>>>> >>
>>>>> >> ....
>>>>> >>
>>>>> >> [ system ]
>>>>> >> protein+ligand+water
>>>>> >>
>>>>> >> [ molecules ]
>>>>> >> protein 1 ; 2000 atoms, nr 1-2000
>>>>> >> ligand 1 ; 10 atoms, nr 2001-2010
>>>>> >> water 10000
>>>>> >>
>>>>> >> [ intermolecular-interactions ]
>>>>> >> ; any bonded type(s) using 2 atoms or more which is a potential
>>>>> (e.g. no
>>>>> >> vsite, constraints) and does not generate exclusions can follow
>>>>> >>
>>>>> >> [ angles ]
>>>>> >> 803 804 2002 1 30.0 100.0 ; angle potential between 2 protein
>>>>> atoms
>>>>> >> and 1 ligand atom
>>>>> >>
>>>>> >> ...
>>>>> >>
>>>>> >> Cheers,
>>>>> >>
>>>>> >> Berk
>>>>> >>
>>>>> >> On 08/30/2013 11:51 PM, Shirts, Michael (mrs5pt) wrote:
>>>>> >>> Berk, just following up on the requests below to make it easier to
>>>>> test the
>>>>> >>> code:
>>>>> >>>
>>>>> >>> Thanks!
>>>>> >>> ~~~~~~~~~~~~
>>>>> >>> Michael Shirts
>>>>> >>> Assistant Professor
>>>>> >>> Department of Chemical Engineering
>>>>> >>> University of Virginia
>>>>> >>> michael.shirts at virginia.edu
>>>>> >>> (434)-243-1821
>>>>> >>>
>>>>> >>>
>>>>> >>>> From: "Michael R. Shirts" <mrs5pt at eservices.virginia.edu>
>>>>> >>>> Reply-To: <michael.shirts at virginia.edu>
>>>>> >>>> Date: Wed, 21 Aug 2013 10:09:55 -0400
>>>>> >>>> To: Discussion list for GROMACS development <
>>>>> gmx-developers at gromacs.org>
>>>>> >>>> Subject: Re: [gmx-developers] free energy calculations with
>>>>> restraints
>>>>> >>>>
>>>>> >>>> Hi, Berk-
>>>>> >>>>
>>>>> >>>> * Would it be possible to post (perhaps to redmine?) some example
>>>>> files of
>>>>> >>>> calling usage?
>>>>> >>>>
>>>>> >>>> * Perhaps you can provide a bit more of the logic for how this is
>>>>> >>>> implemented? I was expecting a new interaction_function type, but
>>>>> this seems
>>>>> >>>> to be done somewhat differently, and I'm not quite sure how it
>>>>> works -- I
>>>>> >>>> suspect other people will be confused as well.
>>>>> >>>>
>>>>> >>>> Best,
>>>>> >>>> ~~~~~~~~~~~~
>>>>> >>>> Michael Shirts
>>>>> >>>> Assistant Professor
>>>>> >>>> Department of Chemical Engineering
>>>>> >>>> University of Virginia
>>>>> >>>> michael.shirts at virginia.edu
>>>>> >>>> (434)-243-1821
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>> From: Berk Hess <hess at kth.se>
>>>>> >>>>> Reply-To: Discussion list for GROMACS development
>>>>> >>>>> <gmx-developers at gromacs.org>
>>>>> >>>>> Date: Wed, 21 Aug 2013 17:47:42 +0200
>>>>> >>>>> To: Discussion list for GROMACS development <
>>>>> gmx-developers at gromacs.org>
>>>>> >>>>> Subject: Re: [gmx-developers] free energy calculations with
>>>>> restraints
>>>>> >>>>>
>>>>> >>>>> Hi,
>>>>> >>>>>
>>>>> >>>>> I pushed up a patch to gerrit (master) which is complete afaik,
>>>>> but with
>>>>> >>>>> a change as extensive as this, there is always a chance I
>>>>> overlooked
>>>>> >>>>> something:
>>>>> >>>>> https://gerrit.gromacs.org/#/c/2566/
>>>>> >>>>>
>>>>> >>>>> Please try and report back!
>>>>> >>>>>
>>>>> >>>>> Cheers,
>>>>> >>>>>
>>>>> >>>>> Berk
>>>>> >>>>>
>>>>> >>>>> On 08/21/2013 10:08 AM, Mark Abraham wrote:
>>>>> >>>>>> Hi,
>>>>> >>>>>>
>>>>> >>>>>> I've been following with interest, and Berk and I discussed
>>>>> these
>>>>> >>>>>> issues yesterday. I'd been afraid there would be artifacts of
>>>>> >>>>>> "[moleculetype] is self-contained and exclusive" all through
>>>>> the code,
>>>>> >>>>>> but Berk seems pretty sure that's not the case. The kind of
>>>>> >>>>>> [intermolecule-interactions] suggested above sounds great to
>>>>> me, as a
>>>>> >>>>>> potential building block for all sorts of things.
>>>>> >>>>>>
>>>>> >>>>>> Mark
>>>>> >>>>>>
>>>>> >>>>>> On Tue, Aug 20, 2013 at 7:12 PM, David Mobley <
>>>>> dmobley at gmail.com> wrote:
>>>>> >>>>>>> Yes, I'm very enthusiastic about adding defined intermolecular
>>>>> restraints
>>>>> >>>>>>> using absolute atom indices. It seems like a straightforward,
>>>>> correct,
>>>>> >>>>>>> easy-to-understand way to deal with this simple problem.
>>>>> >>>>>>>
>>>>> >>>>>>> David
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> On Tue, Aug 20, 2013 at 9:39 AM, Shirts, Michael (mrs5pt)
>>>>> >>>>>>> <mrs5pt at eservices.virginia.edu> wrote:
>>>>> >>>>>>>> The other thing I would say is that the couple-mol code is a
>>>>> little
>>>>> >>>>>>>> difficult to work with----there's known quirks, like handling
>>>>> the
>>>>> >>>>>>>> intramolecular dispersion in a way that's slightly off from
>>>>> free energy
>>>>> >>>>>>>> off,
>>>>> >>>>>>>> as well as some new quirks that I'll try to post about later
>>>>> this
>>>>> >>>>>>>> week---that it would actually be cleaner to add clearly
>>>>> defined
>>>>> >>>>>>>> intermolecular restraints than add complexity to the coupling
>>>>> feature.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Best,
>>>>> >>>>>>>> ~~~~~~~~~~~~
>>>>> >>>>>>>> Michael Shirts
>>>>> >>>>>>>> Assistant Professor
>>>>> >>>>>>>> Department of Chemical Engineering
>>>>> >>>>>>>> University of Virginia
>>>>> >>>>>>>> michael.shirts at virginia.edu
>>>>> >>>>>>>> (434)-243-1821
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>>> From: Floris Buelens <floris_buelens at yahoo.com>
>>>>> >>>>>>>>> Reply-To: Floris Buelens <floris_buelens at yahoo.com>,
>>>>> Discussion list
>>>>> >>>>>>>>> for
>>>>> >>>>>>>>> GROMACS development <gmx-developers at gromacs.org>
>>>>> >>>>>>>>> Date: Tue, 20 Aug 2013 08:35:15 -0400
>>>>> >>>>>>>>> To: Berk Hess <hess at kth.se>, Discussion list for GROMACS
>>>>> development
>>>>> >>>>>>>>> <gmx-developers at gromacs.org>
>>>>> >>>>>>>>> Subject: Re: [gmx-developers] free energy calculations with
>>>>> restraints
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Hi Berk,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I think we might have gone out of sync there - I sent the
>>>>> message below
>>>>> >>>>>>>>> before
>>>>> >>>>>>>>> reading yours from this morning. From the misplaced context
>>>>> it maybe
>>>>> >>>>>>>>> sounded
>>>>> >>>>>>>>> like I was disagreeing with your '[
>>>>> intermolecular-interactions ]'
>>>>> >>>>>>>>> suggestion,
>>>>> >>>>>>>>> which I'm definitely not - this would clearly be preferable
>>>>> and
>>>>> >>>>>>>>> probably
>>>>> >>>>>>>>> useful to a wider audience.
>>>>> >>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> ----- Original Message -----
>>>>> >>>>>>>>> From: Berk Hess <hess at kth.se>
>>>>> >>>>>>>>> To: Floris Buelens <floris_buelens at yahoo.com>; Discussion
>>>>> list for
>>>>> >>>>>>>>> GROMACS
>>>>> >>>>>>>>> development <gmx-developers at gromacs.org>
>>>>> >>>>>>>>> Cc:
>>>>> >>>>>>>>> Sent: Tuesday, 20 August 2013, 12:04
>>>>> >>>>>>>>> Subject: Re: [gmx-developers] free energy calculations with
>>>>> restraints
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Hi,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> We could consider this.
>>>>> >>>>>>>>> I don't know how you did this now, but this would need an
>>>>> extra mdp
>>>>> >>>>>>>>> option, something like couple-group, to avoid one option
>>>>> with a moltype
>>>>> >>>>>>>>> or index group as an input.
>>>>> >>>>>>>>> Then we would also need to decide what to do with a group
>>>>> which is part
>>>>> >>>>>>>>> of one molecule of a certain moleculetype with multiple
>>>>> copies.
>>>>> >>>>>>>>> Disallow
>>>>> >>>>>>>>> this? Or duplicate the moltype and only modify one copy (as
>>>>> is done now
>>>>> >>>>>>>>> for qmmm)?
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Cheers,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Berk
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On 08/20/2013 09:24 AM, Floris Buelens wrote:
>>>>> >>>>>>>>>> Hi,
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> I would also still argue for augmenting the current
>>>>> couple-moltype
>>>>> >>>>>>>>>> functionality with this modification. I can see this is a
>>>>> niche
>>>>> >>>>>>>>>> requirement,
>>>>> >>>>>>>>>> which of course does speak against inclusion. But in my
>>>>> view the
>>>>> >>>>>>>>>> replacement
>>>>> >>>>>>>>>> code is no less elegant than the current implementation
>>>>> (modification
>>>>> >>>>>>>>>> of five
>>>>> >>>>>>>>>> self-contained functions at the pre-processing stage, maybe
>>>>> 50-odd
>>>>> >>>>>>>>>> extra
>>>>> >>>>>>>>>> lines), we can maintain full backward compatibility, and a
>>>>> single
>>>>> >>>>>>>>>> simple
>>>>> >>>>>>>>>> check will remove any potential for accidental misuse.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> ________________________________
>>>>> >>>>>>>>>> From: David Mobley <dmobley at uci.edu>
>>>>> >>>>>>>>>> To: Discussion list for GROMACS development
>>>>> >>>>>>>>>> <gmx-developers at gromacs.org>
>>>>> >>>>>>>>>> Cc: Floris Buelens <floris_buelens at yahoo.com>; Michael R.
>>>>> Shirts
>>>>> >>>>>>>>>> <michael.shirts at virginia.edu>
>>>>> >>>>>>>>>> Sent: Monday, 19 August 2013, 20:02
>>>>> >>>>>>>>>> Subject: Re: [gmx-developers] free energy calculations with
>>>>> restraints
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Hi, Berk,
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> I agree that this solution would be the "proper" one and
>>>>> would be
>>>>> >>>>>>>>>> nice.
>>>>> >>>>>>>>>> However, it's been a long time coming (this is an issue
>>>>> I've been
>>>>> >>>>>>>>>> raising for
>>>>> >>>>>>>>>> approximately 5 years, and there's no progress; normally no
>>>>> one even
>>>>> >>>>>>>>>> answers). Currently, for the restraints I need to use, I
>>>>> *have* to
>>>>> >>>>>>>>>> merge the
>>>>> >>>>>>>>>> ligand into my protein topology, inconvenient or not. Doing
>>>>> this also
>>>>> >>>>>>>>>> means
>>>>> >>>>>>>>>> there are some features I simply can't use (couple-moltype
>>>>> for
>>>>> >>>>>>>>>> example).
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> It strikes me that Floris's solution is a good interim one,
>>>>> in that it
>>>>> >>>>>>>>>> at
>>>>> >>>>>>>>>> least solves most of the typical use cases we're facing,
>>>>> and has the
>>>>> >>>>>>>>>> advantage of being *already implemented*.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Is there any way we could get this into the main GROMACS,
>>>>> at least
>>>>> >>>>>>>>>> until
>>>>> >>>>>>>>>> someone gets time to implementing the "proper" solution
>>>>> (which could
>>>>> >>>>>>>>>> be
>>>>> >>>>>>>>>> years
>>>>> >>>>>>>>>> from now)?
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Thanks!
>>>>> >>>>>>>>>> David
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On Mon, Aug 19, 2013 at 1:10 AM, Berk Hess <hess at kth.se>
>>>>> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Hi,
>>>>> >>>>>>>>>>> I fully understood this point, maybe my reply wasn't well
>>>>> structured.
>>>>> >>>>>>>>>>> I was trying to argue that the proper solution would be to
>>>>> implement
>>>>> >>>>>>>>>>> inter-molecular restraints, instead of introducing an
>>>>> option which
>>>>> >>>>>>>>>>> could me
>>>>> >>>>>>>>>>> misused. Also merging a ligand topology into your protein
>>>>> topology is
>>>>> >>>>>>>>>>> very
>>>>> >>>>>>>>>>> inconvenient. This problem with the proper solution is, of
>>>>> course,
>>>>> >>>>>>>>>>> that
>>>>> >>>>>>>>>>> someone will need to implement inter-molecular
>>>>> restraints/potentials.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> One issue used to be that we corrected molecules for PBC
>>>>> before
>>>>> >>>>>>>>>>> calculating
>>>>> >>>>>>>>>>> bonded interactions. But in 4.6 this is usually not faster
>>>>> and not
>>>>> >>>>>>>>>>> used any
>>>>> >>>>>>>>>>> more. That makes it easier to treat intra- and
>>>>> inter-molecular
>>>>> >>>>>>>>>>> interactions
>>>>> >>>>>>>>>>> the same way at the mdrun level.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Cheers,
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Berk
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> On 08/19/2013 09:55 AM, Floris Buelens wrote:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Hi Berk,
>>>>> >>>>>>>>>>>> I think some clarification is needed. What we're talking
>>>>> about is
>>>>> >>>>>>>>>>>> only
>>>>> >>>>>>>>>>>> relevant in the context of non-bonded interactions,
>>>>> typically
>>>>> >>>>>>>>>>>> between
>>>>> >>>>>>>>>>>> a
>>>>> >>>>>>>>>>>> small molecule and a protein. To access the binding
>>>>> affinity of a
>>>>> >>>>>>>>>>>> ligand
>>>>> >>>>>>>>>>>> through alchemical methods, it's useful to switch off
>>>>> only the
>>>>> >>>>>>>>>>>> interactions
>>>>> >>>>>>>>>>>> of the ligand with its environment while maintaining
>>>>> intra-ligand
>>>>> >>>>>>>>>>>> potentials - this is what's provided by the
>>>>> 'couple-moltype' code
>>>>> >>>>>>>>>>>> path.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> The limitation that we're trying to circumvent comes from
>>>>> the fact
>>>>> >>>>>>>>>>>> that as
>>>>> >>>>>>>>>>>> you scale down interactions with the environment, the
>>>>> ligand is no
>>>>> >>>>>>>>>>>> longer
>>>>> >>>>>>>>>>>> held in the binding site. To counteract this, it's
>>>>> necessary to
>>>>> >>>>>>>>>>>> perturb in
>>>>> >>>>>>>>>>>> restraining potentials as the intramolecular nonbonded
>>>>> interactions
>>>>> >>>>>>>>>>>> are
>>>>> >>>>>>>>>>>> perturbed out. The most practical method makes use of a
>>>>> single
>>>>> >>>>>>>>>>>> distance
>>>>> >>>>>>>>>>>> restraint, two angle and three dihedral restraints, whose
>>>>> effect can
>>>>> >>>>>>>>>>>> later
>>>>> >>>>>>>>>>>> be accounted for analytically.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> The current code only allows decoupling of a whole logical
>>>>> >>>>>>>>>>>> 'molecule'
>>>>> >>>>>>>>>>>> as
>>>>> >>>>>>>>>>>> specified in the topology file. This precludes the use of
>>>>> regular
>>>>> >>>>>>>>>>>> (fully
>>>>> >>>>>>>>>>>> perturbation-aware) bonded interactions. As far as I'm
>>>>> aware, the
>>>>> >>>>>>>>>>>> pull code
>>>>> >>>>>>>>>>>> doesn't provide what's required. Inter-molecular bonded
>>>>> interactions
>>>>> >>>>>>>>>>>> would
>>>>> >>>>>>>>>>>> be a great general solution but presumably won't show up
>>>>> any time
>>>>> >>>>>>>>>>>> soon.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> The workaround here is instead to represent two physical
>>>>> molecules
>>>>> >>>>>>>>>>>> (e.g.
>>>>> >>>>>>>>>>>> protein and ligand) as a single logical molecule (in the
>>>>> topology
>>>>> >>>>>>>>>>>> file), so
>>>>> >>>>>>>>>>>> regular bonded potentials can be applied. Current Gromacs
>>>>> doesn't
>>>>> >>>>>>>>>>>> allow the
>>>>> >>>>>>>>>>>> decoupling ('couple-moltype') code to be used in this
>>>>> scenario. My
>>>>> >>>>>>>>>>>> modification allows you to target the ligand by its
>>>>> residue name and
>>>>> >>>>>>>>>>>> get
>>>>> >>>>>>>>>>>> this functionality back.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Decoupling a single residue of a multi-residue chain is
>>>>> indeed
>>>>> >>>>>>>>>>>> probably not
>>>>> >>>>>>>>>>>> correct in this framework (I did call it 'weird' in my
>>>>> last message
>>>>> >>>>>>>>>>>> :-) ).
>>>>> >>>>>>>>>>>> An extra check would block users from trying this.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> I hope that clarifies the problem we're trying to solve.
>>>>> I agree
>>>>> >>>>>>>>>>>> this
>>>>> >>>>>>>>>>>> will
>>>>> >>>>>>>>>>>> be useful a relatively small number of users, but on the
>>>>> other hand
>>>>> >>>>>>>>>>>> it's a
>>>>> >>>>>>>>>>>> very unobtrusive, self-contained modification which can
>>>>> maintain
>>>>> >>>>>>>>>>>> full
>>>>> >>>>>>>>>>>> backwards compatibility.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> thanks,
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Floris
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> ----- Original Message -----
>>>>> >>>>>>>>>>>> From: Berk Hess <hess at kth.se>
>>>>> >>>>>>>>>>>> To: Floris Buelens <floris_buelens at yahoo.com>;
>>>>> Discussion list for
>>>>> >>>>>>>>>>>> GROMACS
>>>>> >>>>>>>>>>>> development <gmx-developers at gromacs.org>
>>>>> >>>>>>>>>>>> Cc:
>>>>> >>>>>>>>>>>> Sent: Monday, 19 August 2013, 9:03
>>>>> >>>>>>>>>>>> Subject: Re: [gmx-developers] free energy calculations
>>>>> with
>>>>> >>>>>>>>>>>> restraints
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> There is the rotational pull code, but that might not
>>>>> provide the
>>>>> >>>>>>>>>>>> exact
>>>>> >>>>>>>>>>>> functionality you want.
>>>>> >>>>>>>>>>>> Already for some time we have been discussing
>>>>> inter-molecular
>>>>> >>>>>>>>>>>> interactions, by specifying molecule type, molecule index
>>>>> and atom
>>>>> >>>>>>>>>>>> index, but there are no concrete plans for implementing
>>>>> this yet.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> An option for decoupling part of a molecule indeed sound
>>>>> useful. But
>>>>> >>>>>>>>>>>> in
>>>>> >>>>>>>>>>>> practice you always need to replace that part by
>>>>> something else, at
>>>>> >>>>>>>>>>>> least a hydrogen, and modify some potentials of
>>>>> connecting atoms, so
>>>>> >>>>>>>>>>>> I
>>>>> >>>>>>>>>>>> don't know how generally useful such an option is.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Cheers,
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Berk
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> On 08/19/2013 07:56 AM, Floris Buelens wrote:
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> I suppose that would make sense. The changes are fairly
>>>>> minor (more
>>>>> >>>>>>>>>>>> or less
>>>>> >>>>>>>>>>>> just the function convert_moltype_couple and the four
>>>>> functions it
>>>>> >>>>>>>>>>>> calls)
>>>>> >>>>>>>>>>>> and mainly consist of a bit of extra juggling with
>>>>> nonbonded
>>>>> >>>>>>>>>>>> exclusions
>>>>> >>>>>>>>>>>> during preprocessing. The current functionality (decouple
>>>>> a whole
>>>>> >>>>>>>>>>>> molecule)
>>>>> >>>>>>>>>>>> could be handled as a special case of the new code. A
>>>>> check for
>>>>> >>>>>>>>>>>> bonds
>>>>> >>>>>>>>>>>> to
>>>>> >>>>>>>>>>>> the rest of the structure could stop people from trying
>>>>> weird stuff
>>>>> >>>>>>>>>>>> like
>>>>> >>>>>>>>>>>> decoupling residues from a chain.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> ________________________________
>>>>> >>>>>>>>>>>>> From: David Mobley <dmobley at gmail.com>
>>>>> >>>>>>>>>>>>> To: Floris Buelens <floris_buelens at yahoo.com>
>>>>> >>>>>>>>>>>>> Cc: Discussion list for GROMACS development
>>>>> >>>>>>>>>>>>> <gmx-developers at gromacs.org>
>>>>> >>>>>>>>>>>>> Sent: Friday, 16 August 2013, 18:30
>>>>> >>>>>>>>>>>>> Subject: Re: [gmx-developers] free energy calculations
>>>>> with
>>>>> >>>>>>>>>>>>> restraints
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> This does sound useful, though it would be more useful
>>>>> if this
>>>>> >>>>>>>>>>>>> could
>>>>> >>>>>>>>>>>>> be
>>>>> >>>>>>>>>>>>> implemented into the main GROMACS rather than a separate
>>>>> code
>>>>> >>>>>>>>>>>>> (since
>>>>> >>>>>>>>>>>>> otherwise it will go away as GROMACS is further
>>>>> developed).
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Would this be a possibility going forward, devels?
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Thanks!
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> On Fri, Aug 16, 2013 at 3:07 AM, Floris Buelens
>>>>> >>>>>>>>>>>>> <floris_buelens at yahoo.com>
>>>>> >>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Hi David,
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> I have the same requirement as you, but I've gone about
>>>>> it slightly
>>>>> >>>>>>>>>>>>> differently. I've hacked the couple-moltype code path to
>>>>> allow
>>>>> >>>>>>>>>>>>> decoupling
>>>>> >>>>>>>>>>>>> of a specific residue (identified by name) instead of a
>>>>> molecule.
>>>>> >>>>>>>>>>>>> This
>>>>> >>>>>>>>>>>>> allows the residue of interest to be part of another
>>>>> molecule block
>>>>> >>>>>>>>>>>>> so you
>>>>> >>>>>>>>>>>>> can set up distance, angle and dihedral restraints using
>>>>> regular
>>>>> >>>>>>>>>>>>> bonded
>>>>> >>>>>>>>>>>>> interactions with full perturbation support.
>>>>> >>>>>>>>>>>>> If this is useful to you or to anyone else, let me know
>>>>> and I'll be
>>>>> >>>>>>>>>>>>> happy
>>>>> >>>>>>>>>>>>> to share.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> best,
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Floris
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> ________________________________
>>>>> >>>>>>>>>>>>> From: David Mobley <dmobley at gmail.com>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> To: Discussion list for GROMACS development
>>>>> >>>>>>>>>>>>> <gmx-developers at gromacs.org>
>>>>> >>>>>>>>>>>>> Sent: Friday, 14 June 2013, 21:47
>>>>> >>>>>>>>>>>>> Subject: [gmx-developers] free energy calculations with
>>>>> restraints
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Hi, devs,
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> I'm writing with an issue relating to the interplay of
>>>>> new free
>>>>> >>>>>>>>>>>>> energy
>>>>> >>>>>>>>>>>>> features with restraints.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> I'm very much appreciating some of the new free energy
>>>>> features in
>>>>> >>>>>>>>>>>>> gromacs, such as the 'couple-moltype' option which
>>>>> provides a way
>>>>> >>>>>>>>>>>>> to set
>>>>> >>>>>>>>>>>>> up decoupling or annihilation of a specific molecule via
>>>>> free
>>>>> >>>>>>>>>>>>> energy
>>>>> >>>>>>>>>>>>> calculations without having to edit the topology file
>>>>> directly.
>>>>> >>>>>>>>>>>>> This is
>>>>> >>>>>>>>>>>>> especially great when it comes to decoupling -- charge
>>>>> decoupling
>>>>> >>>>>>>>>>>>> was not
>>>>> >>>>>>>>>>>>> previously possible via topology file editing, and vdW
>>>>> decoupling
>>>>> >>>>>>>>>>>>> took
>>>>> >>>>>>>>>>>>> substantial manipulation of the topology file.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> However, for binding free energies, my work employs
>>>>> orientational
>>>>> >>>>>>>>>>>>> restraints between the protein and ligand. I need to be
>>>>> able to
>>>>> >>>>>>>>>>>>> impose
>>>>> >>>>>>>>>>>>> both dihedral and angle restraints on angles between the
>>>>> protein
>>>>> >>>>>>>>>>>>> and
>>>>> >>>>>>>>>>>>> ligand. Currently, I do this using angle-restraints and
>>>>> >>>>>>>>>>>>> dihedral-restraints. This requires that both the protein
>>>>> and ligand
>>>>> >>>>>>>>>>>>> be
>>>>> >>>>>>>>>>>>> within the same logical 'molecule', which
>>>>> (unfortunately) means
>>>>> >>>>>>>>>>>>> that I
>>>>> >>>>>>>>>>>>> can't make use of the new free energy features above,
>>>>> since
>>>>> >>>>>>>>>>>>> couple-moltype has to apply to a whole molecule, not
>>>>> just part of a
>>>>> >>>>>>>>>>>>> molecule.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> So, my I see two possible solutions to the problem, and
>>>>> hence have
>>>>> >>>>>>>>>>>>> these
>>>>> >>>>>>>>>>>>> questions:
>>>>> >>>>>>>>>>>>> 1) Can dihedral and angle restraints be applied via the
>>>>> pull code?
>>>>> >>>>>>>>>>>>> If
>>>>> >>>>>>>>>>>>> not, are there any plans to add that?
>>>>> >>>>>>>>>>>>> 2) Alternatively, what about modifying the restraints
>>>>> code so it
>>>>> >>>>>>>>>>>>> uses (or
>>>>> >>>>>>>>>>>>> at least optionally allows) absolute atom numbering,
>>>>> rather than
>>>>> >>>>>>>>>>>>> numbering within a specific molecule, thus allowing
>>>>> restraints
>>>>> >>>>>>>>>>>>> (angle-restraints and dihedral-restraints) to be applied
>>>>> between
>>>>> >>>>>>>>>>>>> 'molecules'?
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Thanks!
>>>>> >>>>>>>>>>>>> David
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> --
>>>>> >>>>>>>>>>>>> David Mobley
>>>>> >>>>>>>>>>>>> dmobley at gmail.com
>>>>> >>>>>>>>>>>>> 949-385-2436
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> --
>>>>> >>>>>>>>>>>>> gmx-developers mailing list
>>>>> >>>>>>>>>>>>> gmx-developers at gromacs.org
>>>>> >>>>>>>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> >>>>>>>>>>>>> Please don't post (un)subscribe requests to the list.
>>>>> Use the
>>>>> >>>>>>>>>>>>> www interface or send it to
>>>>> gmx-developers-request at gromacs.org.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>> --
>>>>> >>>>>>>>>>> gmx-developers mailing list
>>>>> >>>>>>>>>>> gmx-developers at gromacs.org
>>>>> >>>>>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> >>>>>>>>>>> Please don't post (un)subscribe requests to the list. Use
>>>>> the www
>>>>> >>>>>>>>>>> interface
>>>>> >>>>>>>>>>> or send it to gmx-developers-request at gromacs.org.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>> --
>>>>> >>>>>>>>> gmx-developers mailing list
>>>>> >>>>>>>>> gmx-developers at gromacs.org
>>>>> >>>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> >>>>>>>>> Please don't post (un)subscribe requests to the list. Use the
>>>>> >>>>>>>>> www interface or send it to
>>>>> gmx-developers-request at gromacs.org.
>>>>> >>>>>>>> --
>>>>> >>>>>>>> gmx-developers mailing list
>>>>> >>>>>>>> gmx-developers at gromacs.org
>>>>> >>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> >>>>>>>> Please don't post (un)subscribe requests to the list. Use the
>>>>> >>>>>>>> www interface or send it to
>>>>> gmx-developers-request at gromacs.org.
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> --
>>>>> >>>>>>> David Mobley
>>>>> >>>>>>> dmobley at gmail.com
>>>>> >>>>>>> 949-385-2436
>>>>> >>>>>>>
>>>>> >>>>>>> --
>>>>> >>>>>>> gmx-developers mailing list
>>>>> >>>>>>> gmx-developers at gromacs.org
>>>>> >>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> >>>>>>> Please don't post (un)subscribe requests to the list. Use the
>>>>> >>>>>>> www interface or send it to gmx-developers-request at gromacs.org
>>>>> .
>>>>> >>>>> --
>>>>> >>>>> gmx-developers mailing list
>>>>> >>>>> gmx-developers at gromacs.org
>>>>> >>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> >>>>> Please don't post (un)subscribe requests to the list. Use the
>>>>> >>>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>>> >>
>>>>> >
>>>>> > --
>>>>> > gmx-developers mailing list
>>>>> > gmx-developers at gromacs.org
>>>>> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> > Please don't post (un)subscribe requests to the list. Use the
>>>>> > www interface or send it to gmx-developers-request at gromacs.org.
>>>>>
>>>>
>>>>
>>>> --
>>>> Gromacs Developers mailing list
>>>>
>>>> * Please search the archive at
>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_Listbefore 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-developersor send a mail to
>>>> gmx-developers-request at gromacs.org.
>>>>
>>>
>>>
>>>
>>> --
>>> David Mobley
>>> dmobley at gmail.com
>>> 949-385-2436
>>> --
>>> Gromacs Developers mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_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-developersor send a mail to
>>> gmx-developers-request at gromacs.org.
>>>
>>>
>>>
>>> --
>>> Gromacs Developers mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_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-developersor send a mail to
>>> gmx-developers-request at gromacs.org.
>>>
>>
>>
>>
>> --
>> David Mobley
>> dmobley at gmail.com
>> 949-385-2436
>>
>
>
>
> --
> David Mobley
> dmobley at gmail.com
> 949-385-2436
>
--
David Mobley
dmobley at gmail.com
949-385-2436
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140307/84a81e6d/attachment-0001.html>
More information about the gromacs.org_gmx-developers
mailing list