[CP2K-user] [CP2K:16481] Energy explosion when atom count increases with HFX. Issue with auxiliary basis sets?

[S Ling]

Hi Nick,

I don't know why the condition number of the overlap matrix with the FIT3
basis is unfavorable in the case of bulk C, so I don't know any other
issues where this might pop-up. Please make sure you are happy with results
before you use the optFIT3 ADMM basis for production run, as I had
to sacrifice some accuracy during the basis optimisation in order to get a
better conditioned basis set.

SL


On Thu, 20 Jan 2022 at 17:17, Nicholas Winner <nwinner at berkeley.edu> wrote:

>
> Thank you Ling. I had read this paper and noticed this problem before. I
> had even asked a similar question before on here, but the manifestation was
> slow convergence rather than divergence. I did not know that any of these
> optFIT basis sets were available.
>
> Using the optFIT you provided, I was able to converge alpha boron without
> much issue. Do you know of any other issues where this might pop-up? i.e.
> is this just an issue of boron and carbon?
>
>
> On Thursday, January 20, 2022 at 2:36:57 AM UTC-8 S Ling wrote:
>
>> 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 <nwi... 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+uns... 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/7b09c117-4c32-4b1d-9e77-257228e6401cn%40googlegroups.com
> <https://groups.google.com/d/msgid/cp2k/7b09c117-4c32-4b1d-9e77-257228e6401cn%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_XY5z4NABADiwwfKTdcuksLemhMmLKT7wKJjEG_BLfUCXWg%40mail.gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20220121/44491e12/attachment.htm>