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
Document that it is not save to reuse SCF callbacks #504
Comments
Did you request super small tolerances? Can you post a MWE? |
No, the tol is at it's default value. I might be able to, but the program is quite large and fractured. Would that mean that the issue would most likely lie in the setup of the scf? Or could it be in the PlaneWaveBasis? |
I used to have this issue when I was recycling the electron density information for the next calculation. The fix for that was to stop recycling the electron density. |
The first couple solved scf's do not experience this issue. Only after a few solved scf iterations does this start to happen. |
Could it be that you are running a very large calculation? How many electrons and bands do you have? It could be that our diagtol heuristics is simply very bad for large problems and requests a tolerance that cannot be delivered by the LOBPCG in 200 iterations. We probably need to adapt the heuristics for such cases ... I remember looking at that in QE and finding out that they do some more tricks. We should probably test our heuristics some more on these cases. |
Number of electrons: 34 |
The above file is a MWE. The file has 1281 lines, so if you have any questions just ask. You should be able to copy and paste this code into a julia file and run it. It takes a few iterations in either the lattice optimization, or the atom optimization for the Eigensolver to not converge. NOTE: This file does create files for saved data. |
I found was was happening. The tolerance on EDITS: Added more necessary information |
After some more tests I found that the clamp function isn't working as expected |
I'm not sure how, but after a hacky fix the first iteration could still drop below the allowed minimum value. This suggests that some information is being passed from one |
It looks like you are calling ScfDiagtol, saving it and then reusing it for several calls to self_consistent_field(). That's indeed going to do bad things, and not expected at all by our code (and I'm not sure we could solve that elegantly). Just use a new ScfDiagtol struct for each call to self_consistent_field. Looking at your code, I see that you specify explicitly the kwargs to self_consistent_field, why are you doing this? |
To be clear: ScfDiagtol is a closure, ie it stores some information implicitly by capturing its kwarg in the inner function |
Actually not only One way we could avoid this problem is by converting them to proper structs and implementing a reset mechanism, but I'm not too sure if that not overcomplicates things. edit: In your example this concerns in particular the |
I think we should add a note to the documentation that makes this statefulness of the callbacks more clear. |
The reason as to why I specify the kwargs explicitly is because the end user of this package wouldn't have direct access to the self_consistent_field function. |
I don't know what you want to do but you can do eg |
Also the |
But that causes trouble for the diagtol mechanism for example. There you need to go to the next level of indirection (i.e. cache the arguments passed to diagtol rather than the diagtol kwarg). I've fallen into that trap as well. |
Yeah, @mfherbst . I've gotten to that point as well. |
Yeah two people falling into that trap sounds like we should do something about it, so good you raised the issue @umbriquse . |
I wrote an optimizer to predict bonding energies, but I am currently running into issues with the Eigensolver not converging in the self_consistent_field function. I'm curious what could be causing this issue.
The text was updated successfully, but these errors were encountered: