-
Notifications
You must be signed in to change notification settings - Fork 455
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 MCSCF Final CI Energy Mismatch #2259
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look reasonable to me. It would probably be good for @CDSherrill to take a look at these changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put these same comments on the forum.
believe @lcyyork is correct in identifying a problem with an ill-defined H0 (small block of H in the determinant basis, formed out of the ~400 “most important” determinants). The problem appears to be that this H0 block was computed in MCSCF macroiteration 0 but never updated… it should be updated each MCSCF macroiteration. I’m not sure why this didn’t cause even more serious MCSCF problems before now (not just for CAS/MCSCF canonical/semicanonical orbitals). Anyway, York’s PR recomputes H0 each macroiteration, which is a good improvement. This is especially true because some of the CI preconditioner options in DETCI use H0 explicitly.
York also modified the code to discard the previous best-guess for the CI vector when the new semicanonical orbitals are obtained. I don’t see why this was necessary. But maybe it is, for some subtle reason. At worst it increases the time to solution a little. If York has time to see what happens NOT including line 371 (ciwfn.set_ci_guess("H0_BLOCK")), I would be curious to see if this still works. (Possibly there are problems because the correction vector is basically zero?). But otherwise I think this is ok as-is.
@CDSherrill Yes, I did try that. Removing line 371 yields the original problem (using the input in the forum, CI space: 792 determinants):
However, with line 371, I get:
I am not sure why reading the old guess leads to very slow convergence. It seems the old vector is not a good guess anymore: the energy from the first sigma build is way off. I actually wonder how the old vector remains to be a good guess during the MCSCF orbital optimization procedure. There is a subtle issue using H0BLOCK for the final CASCI. The MCSCF sets CI max iteration to 12 by default, which is probably not enough to converge a large CI problem. This could be overwritten by the keyword |
Description
Fix the mismatch issue on Github (#2258) and on the forum http://forum.psicode.org/t/slight-mismatching-of-casscf-between-total-mcscf-energy-and-mcscf-root-0-energy/1693/4.
A more efficient way to obtain the CI coefficients after a redundant orbital rotation would be a direct transformation without solving the CI again, see https://doi.org/10.1063/1.479573.
There might be two related issue:
H0block_
in DETCI keeps filling up during the MCSCF macro iteration. This will lead to repeated entries during the MCSCF iterations and sometimes lead to uncertain numerical behavior."DFILE"
CI guess for the CI after orbital canonicalization is directly related to this issue. Using this guess leads to very slow convergence for the CI.Checklist
Status