[CP2K-user] [CP2K:16470] Energy explosion when atom count increases with HFX. Issue with auxiliary basis sets?
S Ling
lingsanliang at gmail.com
Thu Jan 20 10:36:44 UTC 2022
Hi Nick,
If you read the original paper of ADMM (
https://pubs.acs.org/doi/10.1021/ct1002225 ), they mentioned "the condition
number of the overlap matrix with the FIT3 basis is unfavorable in the case
of bulk C", see section 3.6. They produced a separate optFIT3 basis for C
with much more favourable condition number. Unfortunately, I cannot find
the optFIT3 basis for C. I have personally produced an optFIT3 basis for B
if you want to try.
SL
#####
B OPTFIT3
6
1 0 0 1 1
0.27763115800007 1.00000000000000E+00
1 0 0 1 1
3.17679618980955 1.00000000000000E+00
1 0 0 1 1
8.21086367916339 1.00000000000000E+00
1 1 1 1 1
0.15104423596280 1.00000000000000E+00
1 1 1 1 1
0.61295240465023 1.00000000000000E+00
1 1 1 1 1
2.56244918405309 1.00000000000000E+00
#####
On Thu, 20 Jan 2022 at 03:24, Nicholas Winner <nwinner at berkeley.edu> wrote:
> I've been looking at a couple of systems that are atomically pretty dense.
> For example, alpha boron and diamond.
>
> For these systems, when I increase the supercell size too large, the
> energy in the SCF loop explodes to ridiculous values. For example, I am
> calculating diamond with 54 atom and 128 atom supercells, truncated PBE0
> with 2A cutoff.
>
> The 54 atom case converges with no real issues. In that case I have used
> OT, and against common wisdom for really accurate results I screen on the
> initial density matrix with scf_guess atomic. The convergence seems robust
> to that and the aggressive (1e-6) integral screening.
>
> Then, I move to 128 atom supercells, and I am unable to converge as the
> energies diverge rapidly after a few SCF steps. For this case, I have
> stopped screening on the initial density matrix. I was able to narrow the
> issue down to the auxiliary basis sets used for C. I tried cFIT3, pFIT3,
> cpFIT3, and FIT3, which all result in the rapid divergence of the energy.
> Example:
>
>
> 1 OT CG 0.15E+00 141.5 0.01764397 -673.6622732538
> -6.74E+02
>
> 2 OT LS 0.60E+00 35.1 -806.4853195301
>
> 3 OT CG 0.60E+00 38.5 12.03779293 -4186.8334161380
> -3.51E+03
>
> 4 OT LS 0.30E+00 33.7 -8657.0632214970
>
> Since these all failed, but the primary basis is prohibitively large, I
> tried setting BASIS_SET AUX_FIT SZV-MOLOPT-SR-GTH, and this remedies the
> problem, and the calculation finishes.
>
> My questions then are four-fold.
> (1) Is this behavior for dense systems like diamond expected? I have not
> had this issue with any other system besides alpha boron.
> (2) Is this un-fixable? i.e. we can't use the FIT basis sets for such
> systems?
> (3) Would someone have another idea for why this is the case? i.e. maybe
> FIT basis sets can still be used if some other setting was changed.
> and finally (4) Does anyone see an issue with proceeding with using the
> SZV basis as the auxiliary basis?
>
> -Nick
>
> --
> You received this message because you are subscribed to the Google Groups
> "cp2k" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cp2k+unsubscribe at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/cp2k/fc803c56-5e46-4dd8-bf95-d48b33487355n%40googlegroups.com
> <https://groups.google.com/d/msgid/cp2k/fc803c56-5e46-4dd8-bf95-d48b33487355n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+unsubscribe at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/CAJ3_XY4a5aF3oZjrv6pVATKT7t-KtOVr4pm3Yq2Ss59Yv7JwbA%40mail.gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20220120/6f13fc58/attachment.htm>
More information about the CP2K-user
mailing list