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

solver_protocol: "continuation = True" does not exhibit the desired effect? (bug vs. misunderstanding?) #515

Open
denisdertli opened this issue Oct 20, 2023 · 0 comments

Comments

@denisdertli
Copy link

denisdertli commented Oct 20, 2023

Dear community and developers,

I would like to report that I observe that "continuation = True" apparently has not the effect stated in the strategies for solutions [1].

Let us consider the following official example from [1] (where I have deleted "dict(method="hybr"),"):
solver_protocol = (
dict(method="L-BFGS-B", tol = 1.0e-5, continuation = True, options=dict(maxiter=1000)),
dict(method="adaptive", tol = 1.0e-12, options=dict(maxiter=1000,min_sc_iter=5))
)
As far as I understand [1], it should continue with "adaptive" no matter if L-BFGS-B was either successful or not. So, in both cases. And this is exactly what I want. However, I observe that when the first method (here: "L-BFGS-B") was successful, then it does not proceed with "adaptive".

Side note/further information:

A priori, one might wonder, for what reason I want to proceed with another method, when the one before was successful. The background is that some methods lead in my case to the well known subsequent error of the form:
"ParameterError: Warning: Should have \sum_n W_nk = 1. Actual column sum for state 0 was 0.001004. 291 other columns have similar problems.",
e.g., when I call:
"mbar.compute_free_energy_differences()",
although, when I initialized mbar (implicitly via fes, but it also occurs when I directly initialize mbar), there was no error (just a relatively high gradient norm, e.g., 7.71e+04).

This is the reason why I want to continue and end my solver_protocl with "adaptive" which for me always worked (and did not lead to such subsequent errors). However, in many cases it is not convenient for me to directly use "adaptive" because it requires too much time for a few of my data sets (why this is the case is right now unclear to me: One time, it takes time in the order of magnitude 1min and in the other case it is still not done after a few days (although, the simulation results are quite similar)).

In conclusion, I want to first use "method="lm"" which is quickly successful in the first place for me, however, leads to subsequent errors. Therefore, my hope is that I can use the results from "method = "lm"" and pass it to "adaptive" which I hope makes everything fine so that there are no subsequent errors anymore.

I would like to use this opportunity to thank the entire community and developers for the amazing work!

Yours sincerely,

Denis

Refs.
[1] https://pymbar.readthedocs.io/en/master/strategies_for_solution.html

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

1 participant