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

Pymbar 4.0 adaptive logic #446

Merged
merged 17 commits into from
Jul 12, 2022
Merged

Pymbar 4.0 adaptive logic #446

merged 17 commits into from
Jul 12, 2022

Conversation

mrshirts
Copy link
Collaborator

Pass at adding adaptive logic to better converge mbar estimates. Now passes pytest test. Could use a bit more cleaning up, but basic logic is working.

@mrshirts mrshirts requested a review from Lnaden June 29, 2022 05:36
@mrshirts mrshirts marked this pull request as draft June 29, 2022 05:36
@mrshirts
Copy link
Collaborator Author

OK, this appears to have failed with functions returning the error messages that aren't expected. I will check this . . . Interesting that it passed when running pytest locally, but not here.

@mrshirts mrshirts marked this pull request as ready for review June 29, 2022 15:21
@codecov
Copy link

codecov bot commented Jun 29, 2022

Codecov Report

Merging #446 (06c4188) into pymbar4 (2aa90ba) will decrease coverage by 3.18%.
The diff coverage is 50.63%.

Copy link
Member

@jchodera jchodera left a comment

Choose a reason for hiding this comment

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

Shouldn't the robust approach become the default? Other, faster approaches could be selected by the user.

@@ -6,7 +6,7 @@ it, running the tests, and then if successful pushing the package to binstar
(and the docs to AWS S3). The binstar auth token is an encrypted environment
variable generated using:

binstar auth -n repex-travis -o omnia --max-age 22896000 -c --scopes api:write
binstar auth -n repex-travis -o conda-forge --max-age 22896000 -c --scopes api:write
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we're using binstar anymore.

Does this repo need to be updated to the current MolSSI cookiecutter?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Lnaden any thoughts on binstar or updating the cookiecutter?

@@ -224,7 +224,7 @@ def main():
# Initialize MBAR.
print("Running MBAR...")
# TODO: change to u_kn inputs
mbar = pymbar.MBAR(u_kln, N_k, verbose=True, relative_tolerance=1.0e-10)
mbar = pymbar.MBAR(u_kln, N_k, verbose=True, relative_tolerance=1.0e-10, solver_protocol = 'robust')
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't robust be default?

Copy link
Collaborator Author

@mrshirts mrshirts Jul 12, 2022

Choose a reason for hiding this comment

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

That's a good question. I think this is to get the framework right for now, and the precise solvers used will need a bit more experimentation - what is "robust", and what is "default". I'm totally find with using what we think is the most robust for the default, and then having a "faster" option. I will set those solvers in a later PR closer to release after some testing.

@@ -1,50 +1,50 @@
494.896 3701.003313 58.541052
Copy link
Member

Choose a reason for hiding this comment

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

What's the point of including "expected output" targets if this changes even if we are only changing the efficiency and robustness, rather than the expected result? Shouldn't we just adjust the comparison tolerance and keep a single, well-converged set of results here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Reproducibility, basically. They should get the same answer as in the code.

I don't know how to have git compare "up to a number".

dict(method="adaptive", options=dict(min_sc_iter=0)),
)

ROBUST_SOLVER_PROTOCOL = (
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't "robust" be default, with faster methods available if desired?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good question. default is essentially what was done before. I can play around with this a little.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

(and see above for when to release it)

@@ -253,12 +284,11 @@ def adaptive(u_kn, N_k, f_k, tol=1.0e-12, options=None):

options: dictionary of options
gamma (float between 0 and 1) - incrementor for NR iterations (default 1.0). Usually not changed now, since adaptively switch.
maximum_iterations (int) - maximum number of Newton-Raphson iterations (default 250: either NR converges or doesn't, pretty quickly)
maxiter (int) - maximum number of Newton-Raphson iterations (default 10000: either NR converges or doesn't, pretty quickly)
Copy link
Member

Choose a reason for hiding this comment

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

Why change the name from something clear and comprehensible (maximum_iterations) to something shorter (maxiter)? Why change the name at all?

Copy link
Collaborator Author

@mrshirts mrshirts Jul 11, 2022

Choose a reason for hiding this comment

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

These are options that go to either scipy.optimize.minimize or to adaptive, and scipy.optimize.minimize minimizers use maxiter. The idea is to make all of the calls consistent, so you don't have to use maximum_iterations for one solution approach and maxiter for another.

We could just take 'maximum_iterations', and under the hood change it to "maxiter" for the scipy calls, but probably it would be better to just document up front what options it takes.

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.

None yet

2 participants