-
Notifications
You must be signed in to change notification settings - Fork 21
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
Numerical problems with relativistic zora calculations #474
Comments
Here is the NH_4 example where the problem is much more severe:
Once again, I killed the program after it used more than 30 GB of memory. Here this happened already after 7 scf cycles.
|
Just to avoid misunderstandings. You say you run NH_4 but your input clearly shows you are running NH_3. That is OK because NH_4 would be an open shell system, which is not implemented for ZORA + DFT. As for your convergence issues, we are aware that ZORA is not yet very stable as it is, but I'm indeed surprised to see that you get issues already for such small systems. As for the memory issues, if we exclude a possible memory leak, the issue is related to the additional cusp introduced by the For the time being what I can suggest to make the SCF converge in your case is the following:
If none of these works we definitely need to look into this issue. |
Hi Luca Thanks for your quick reply:) Sorry, I meant to say NH3. I will try to change the settings and see if it gets better. About the memory problem: It did not really feel like a memory leak, when I monitored the memory usage, it was constant for quite some time followed by a quick increase when the residual started to rise quickly. Best, |
Hi Luca We tried everything you mentioned except suggestion 3 since I do not know how to do this. Your suggestions help a bit but we still cannot run all of our systems with the desired precision (which is quite high, but this is the reason we would like to use MRCHEM). |
Hi Moritz, sorry I'm late to the party, but I hope I might be of help here.
The "path_orbitals" keyword can be omitted and it will just give you the orbitals in a folder called "orbitals" within the directory of the input file, but I added it here for completeness. Then to use your initial guess, you have to use the following keywords in your actual run's input file
As one can expect, you can repeat this procedure ad nauseam, starting with an extremely low precision initial guess and slowly increasing the precision to whatever your heart desires. Should that not suffice (and sometimes it doesn't), I noticed that sometimes the default world_size parameter is too large which causes enough numerical instability to cause similar problems to what you experienced. In that case, try lowering fro the default 7 (-ish) to 6 or even 5. It helped a couple of times. Another source of issues might be the localisation of orbitals. If all else fails, try this:
Hope that helps with your issue :) |
One more comment from my side: are you using point charges as nuclei or smeared nuclei? For 4d elements you should definitely go for smeared nuclei. |
We used the default setting which I think is point charges. I did not even see the smearing option, that sounds promising. |
Hi
I recently noticed, that I am not able to converge zora calculations with tight precisions. The problem is the following: consider the input file
This does not converge. It is close though, it almost reaches the threshold after 10 SCF iterations. After that the MO residual stays slightly above the convergence threshold for the next 20 SCF iteration. Then the simulation goes really wrong and the residual starts to diverge. Also, the memory required by mrchem continuously grows and after 47 iterations i stopped the program because it used up the entire memory of my workstation (32 GB).
I used the newest version of mrchem and tested the functionals lda, pbe and pbe0 where the problem is the same. It is also present in all the other molecules I tested: H_2O, NH_4, it is even more severe in the NH_4 molecule. When the world_prec is increased to 1e-4 or the zora method is not used, the calculation converges. Below you find the output of the SCF cycle from the input file from above.
I tried to play around with some SCF keywords to get these calculations to converge, but was not able to do so. Do you have an idea what could go wrong here? Thanks a lot for looking into this.
The text was updated successfully, but these errors were encountered: