Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hydration calculation uses extra lambdas in gas #73

Open
davidlmobley opened this issue Nov 3, 2017 · 7 comments
Open

Hydration calculation uses extra lambdas in gas #73

davidlmobley opened this issue Nov 3, 2017 · 7 comments

Comments

@davidlmobley
Copy link
Contributor

The hydration example seems to use extra lambdas in the gas phase:

solvent2:
alchemical_path:
lambda_electrostatics: [1.00, 0.75, 0.50, 0.25, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00]
lambda_sterics: [1.00, 1.00, 1.00, 1.00, 1.00, 0.95, 0.90, 0.85, 0.80, 0.75, 0.70, 0.65, 0.60, 0.50, 0.40, 0.30, 0.20, 0.10, 0.00]

This confused me because I had another example from Andrea Rizzi where he used far fewer lambda values in the gas phase and set lambda_sterics to 1 throughout, which made me think that the thermodynamic cycle was not closing (e.g., if decoupling is being used, there is no reason to change lambda_sterics in the gas phase).

Probably this should be adjusted to alleviate confusion.

@jchodera
Copy link
Member

jchodera commented Nov 3, 2017

I'm not understanding what the stated problem or suggested remedy is. "Extra" compared to what? Which lambda values are "extra"?

@jchodera
Copy link
Member

jchodera commented Nov 3, 2017

if decoupling is being used, there is no reason to change lambda_sterics in the gas phase

If the user changes the type of alchemical treatment (annihilation vs decoupling), that could cause this protocol to be problematic.

@andrrizzi @Lnaden : Do we actually support the specification of annihilation vs decoupling? Or do we force decoupling of LJ and annihilation of electrostatics? We don't actually mention which scheme we use by default in the protocols section of the manual.

@jchodera
Copy link
Member

jchodera commented Nov 3, 2017

Ah! cc: MobleyLab/SMIRNOFF_paper_code#5

@jchodera
Copy link
Member

jchodera commented Nov 3, 2017

Also, you might want to use auto to simplify things:
http://getyank.org/0.18.0/yamlpages/protocols.html#automatic-path-determination

@davidlmobley
Copy link
Contributor Author

I'm not necessarily advocating changing/recommending one way or the other, just noting that at present it's very confusing, as it was unclear to me (without digging or asking) whether you are doing annihilating or decoupling, and the example uses lambda values which would be appropriate for annihilation (but unnecessary and wasteful for decoupling) whereas Andrea's protocol used lambda values which are appropriate for decoupling but incorrect for annihilation. And in neither case was it specified which was being used.

@jchodera
Copy link
Member

jchodera commented Nov 4, 2017

I agree we should try to (1) expose annihilation/decoupling options, and either (2) document these well or make these options explicit.

@andrrizzi
Copy link
Contributor

Do we actually support the specification of annihilation vs decoupling?

Yep! They're documented here: http://getyank.org/0.18.0/yamlpages/options.html#alchemy-parameters .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants