search

MobleyLab / alchemical-analysis

An open tool implementing some recommended practices for analyzing alchemical free energy calculations
MIT License
118 stars 60 forks source link

Generalize handling of other (non-charging/vdW) free energy components, such as for restraints, so that they don't get grouped with vdW #65

Open matteoaldeghi opened 8 years ago

matteoaldeghi commented 8 years ago

A possible small enhancement: since for absolute calculations there is a also a restraints component other than coulomb and vdw, it could be good to have the free energy of this term shown as well in the summary table of the results. At the moment I think the restraints free energy ends up being included in the vdw component, as suggested by the remark.

It might be possible to do this just by modifying slightly the totalEnergies() function? I attach a snippet of quickly modified code which seemed to work for me; it could have some issues though, so it is really just an idea. showrestraints.txt

davidlmobley commented 8 years ago

This idea will work in some cases, though it raises a larger/more general issue of how we ought to handle splitting out energy components at all. Particularly, as part of the larger code revisions currently being thought through, we probably ought to rework all of the splitting into components to: 1) Not split into components at all if none of the components change independently of the others 2) Split into arbitrary appropriate components anytime any components are changing independently of the others

The first is necessary because, to use restraints as an example, I can split the restraining component out separately only if restraining lambda values are changed separately from charging and vdW lambdas. If they are changed at the same time then no separation is possible.

I think it should be possible to do this by just reading the lambda vectors initially and figuring out how to split. But it will complicate the interface for the parsers, plotting, and analysis in that information about the components will have to propagate between these. But I just don't see any other way to deal with this in general without limiting ourselves to specific protocols.

I'm tagging this as an enhancement for now and modifying the title to refer to the more general issue.

halx commented 8 years ago

I'm not sure if I really understand the problem here. Ultimately there is a variable number of free energy/lambda data and as fas as I can see the current Gromacs parser supports this. All that needs to be done then is to extract what datum belongs to which lambda-path and tag accordingly. I assume the .xvg file is appropriately annotated.

On 13 January 2016 at 17:14, David L. Mobley notifications@github.com wrote:

This idea will work in some cases, though it raises a larger/more general issue of how we ought to handle splitting out energy components at all. Particularly, as part of the larger code revisions currently being thought through, we probably ought to rework all of the splitting into components to: 1) Not split into components at all if none of the components change independently of the others 2) Split into arbitrary appropriate components anytime any components are changing independently of the others

The first is necessary because, to use restraints as an example, I can split the restraining component out separately only if restraining lambda values are changed separately from charging and vdW lambdas. If they are changed at the same time then no separation is possible.

I think it should be possible to do this by just reading the lambda vectors initially and figuring out how to split. But it will complicate the interface for the parsers, plotting, and analysis in that information about the components will have to propagate between these. But I just don't see any other way to deal with this in general without limiting ourselves to specific protocols.

I'm tagging this as an enhancement for now and modifying the title to refer to the more general issue.

— Reply to this email directly or view it on GitHub https://github.com/MobleyLab/alchemical-analysis/issues/65#issuecomment-171368036 .

davidlmobley commented 8 years ago

Yes. There's no fundamental problem. I'm just saying the code doesn't split out the free energy components of the total in these more general cases, even though the information to do this is available. So we (meaning people on my end, I suppose) will need to fix it.

On Mon, Jan 18, 2016 at 5:21 AM, Hannes Loeffler notifications@github.com wrote:

I'm not sure if I really understand the problem here. Ultimately there is a variable number of free energy/lambda data and as fas as I can see the current Gromacs parser supports this. All that needs to be done then is to extract what datum belongs to which lambda-path and tag accordingly. I assume the .xvg file is appropriately annotated.

On 13 January 2016 at 17:14, David L. Mobley notifications@github.com wrote:

This idea will work in some cases, though it raises a larger/more general issue of how we ought to handle splitting out energy components at all. Particularly, as part of the larger code revisions currently being thought through, we probably ought to rework all of the splitting into components to: 1) Not split into components at all if none of the components change independently of the others 2) Split into arbitrary appropriate components anytime any components are changing independently of the others

The first is necessary because, to use restraints as an example, I can split the restraining component out separately only if restraining lambda values are changed separately from charging and vdW lambdas. If they are changed at the same time then no separation is possible.

I think it should be possible to do this by just reading the lambda vectors initially and figuring out how to split. But it will complicate the interface for the parsers, plotting, and analysis in that information about the components will have to propagate between these. But I just don't see any other way to deal with this in general without limiting ourselves to specific protocols.

I'm tagging this as an enhancement for now and modifying the title to refer to the more general issue.

— Reply to this email directly or view it on GitHub < https://github.com/MobleyLab/alchemical-analysis/issues/65#issuecomment-171368036

.

— Reply to this email directly or view it on GitHub https://github.com/MobleyLab/alchemical-analysis/issues/65#issuecomment-172526010 .

David Mobley dmobley@gmail.com 949-385-2436

davidlmobley commented 8 years ago

Issue #70 was caused in part by this issue - the code is currently really only set up to handle a case where both Coulomb and vdW transformations are present, and doesn't do a very good job handling arbitrary combinations of other components. Specifically, the transformation in #70 is a simultaneous mass, vdW, and bonded transformation, with no changes to Coulomb interactions.

In dealing with #70, I fixed the code so it will process this case (and label the entireity as a vdW transformation), but the more general case still remains.

The sample data for #70 may be relevant to this issue; it's available at https://www.dropbox.com/sh/vmjh7rmswbg0bd8/AADUpt8622PBUnxill6eOoIma?dl=0.