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

Fix the dE method for AMBER #300

Conversation

xiki-tempula
Copy link
Collaborator

Fix #299

@xiki-tempula xiki-tempula linked an issue Mar 18, 2023 that may be closed by this pull request
@codecov
Copy link

codecov bot commented Mar 18, 2023

Codecov Report

Merging #300 (1d0c750) into master (045f85d) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #300   +/-   ##
=======================================
  Coverage   98.74%   98.74%           
=======================================
  Files          26       26           
  Lines        1747     1749    +2     
  Branches      380      380           
=======================================
+ Hits         1725     1727    +2     
  Misses          2        2           
  Partials       20       20           
Impacted Files Coverage Δ
src/alchemlyb/preprocessing/subsampling.py 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link
Member

@orbeckst orbeckst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need some clarification: From the comments in the issue and PR, it sounds as if GROMACS data were correctly processed while others were not — correct me if I misunderstood. What does happen now to GROMACS data after this change?

Also, if it's a Change then there should be a versionchanged in u_nk2series(). However, it sounds more like a fix to me to bring the code in line with the documentation. What do you think it should be classified as?

CHANGES Outdated

* unreleased

Changes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really a change or shouldn't this be listed as a Fix because it now does what is advertised?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this should be a fix. Sorry.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

versionchanged added

@xiki-tempula
Copy link
Collaborator Author

xiki-tempula commented Mar 20, 2023

I need some clarification: From the comments in the issue and PR, it sounds as if GROMACS data were correctly processed while others were not — correct me if I misunderstood. What does happen now to GROMACS data after this change?

GROMACS data should not be changed. The numerical tests with regard to gromacs is not changed.

For a simulation with lambda=0.5, the Gromacs has

Lambda 0 0.5 1.0
1 -1 0 1

Previously, we just take data[lambda=1.0] = 1
We now do data[lambda=1.0] - data[lambda=0.5] = 1 - 0 = 1

@xiki-tempula
Copy link
Collaborator Author

Sorry, I just noticed that I'm wrong.
For Gromacs, it is true that the column corresponding to the current lambda is 0. However, when we read in the reduced potential, it is the dE corrected by the pV, so this changes the gromacs result as well but to the good side.

Copy link
Member

@orbeckst orbeckst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank for the explanation and digging into what effect the fix will have.

Could you please improve the documentation a little bit? I just want to give users a fair chance to understand where results are changing.

CHANGES Outdated

Fixes
- Change the dE method in u_nk2series to use the difference between two
lambda columns (issue #299, PR #300).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you be more specific what bug was fixed — instead of the word "Change", something like "fixed to now use .... (note: will lead to different results than before) (issue ....)"

If I am a user and look through CHANGES I would want to understand if anything affects me.

@@ -153,6 +153,9 @@ def u_nk2series(df, method="dE"):


.. versionadded:: 1.0.0
.. versionchanged:: 2.0.1
The `dE` method computes the difference between the current lambda
and the next lambda (previous lambda for the last window).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add "... instead of ..." so that people have an idea what behavior changed

@xiki-tempula
Copy link
Collaborator Author

@orbeckst Thanks for the review. I have fixed the doc.

@orbeckst orbeckst self-assigned this Mar 21, 2023
@orbeckst orbeckst merged commit 2c1d153 into master Mar 21, 2023
@orbeckst orbeckst deleted the 299-the-de-method-in-decorrelating-the-u_nk-data-is-not-actually-de branch March 21, 2023 22:17
@orbeckst
Copy link
Member

Thanks @xiki-tempula !

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

Successfully merging this pull request may close these issues.

The dE method in decorrelating the u_nk data is not actually dE
2 participants