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

[matteoaldeghi]

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]

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]

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 [email protected]
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
#65 (comment)
.

[davidlmobley]

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 [email protected]
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 [email protected]
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
<
#65 (comment)

.

—
Reply to this email directly or view it on GitHub
#65 (comment)
.

David Mobley
[email protected]
949-385-2436

[davidlmobley]

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.