comparing CP2K-DFTB (5.1) and DFTB+ (18.2)

1,317 views
Skip to first unread message

Wei Lai

unread,
Dec 18, 2018, 10:49:51 PM12/18/18
to cp2k

Dear CP2K users and developers,

 

I was testing the DFTB functionality of CP2K and comparing it to DFTB+.  I was using Li2O (324 atoms) as an example and the CP2K input file is shown in the following (without the full coordinates). 

 

I found CP2K-DFTB results are very sensitive to the choice of Ewald (SPME which is the only Ewald method available for DFTB) parameter (ALPHA in A^-1).  For a RCUT of 6 A, an estimate of ALPHA is usually 3.5/6=0.583.  These results actually suggest indeed this is a good estimate.

ALPHA Li-Mulliken-charge    H0-energy      Repulsive energy            SCC-energy    Tot energy

0.64     0.571831        -414.5978261 1.790186269            8.302889648  -404.5047502

0.583   0.57183          -414.5978042 1.790186269            8.302909311  -404.5047086

0.5       0.57183          -414.5978156 1.790186269            8.302899133  -404.5047302

0.35     0.572372        -414.6135268 1.790186269            8.288678932  -404.5346616

0.22     0.610178        -415.6039561 1.790186269            7.126741326  -406.6870285

0.219   0.611188        -415.6274692 1.790186269            7.090867312  -406.7464156

 

On the other hand, DFTB+ (using Ewald instead of SPME) results are NOT very sensitive to ALPHA.  I am not sure what is the unit of ALPHA in DFTB+ but I tried several values.  A value of 0.219 (hand tuned) in CP2K gave similar results to those in DFTB+ with an automatic ALPHA value.

ALPHA Li-Mulliken-charge    H0-energy      Repulsive energy            SCC-energy    Tot energy

auto    0.61175023    -415.6390952 1.790189279            7.070521175  -406.7783847

0.338   0.61175319    -415.6391637 1.790189279            7.07041506    -406.7785594

0.64     0.6117653      -415.6394434 1.790189279            7.069981919  -406.7792722

1          0.61178357    -415.6398657 1.790189279            7.069327807  -406.7803486

 

I am puzzled by this comparison and wondering if you have any insight on this.


Thanks, Wei

 

&GLOBAL

  PROJECT Li2O

  RUN_TYPE ENERGY_FORCE

  PRINT_LEVEL LOW

&END GLOBAL

 

&FORCE_EVAL

  STRESS_TENSOR ANALYTICAL

  METHOD QS

  &DFT 

    &QS

      METHOD DFTB

      &DFTB

        SELF_CONSISTENT T

        DO_EWALD        T

        DISPERSION      F

        &PARAMETER

            SK_FILE Li Li     ./Li-Li.skf

            SK_FILE Li O      ./Li-O.skf

            SK_FILE O Li      ./O-Li.skf

            SK_FILE O O       ./O-O.skf

        &END PARAMETER

      &END DFTB     

      EPS_DEFAULT 1.0E-12

      EXTRAPOLATION ASPC

      EXTRAPOLATION_ORDER 2

    &END QS

   

    &SCF                             

      SCF_GUESS RESTART ! can be used to RESTART an interrupted calculation

      MAX_SCF 100

      EPS_SCF 1.0E-7

      ADDED_MOS 216

      CHOLESKY INVERSE

      &SMEAR ON

        METHOD FERMI_DIRAC

        ELECTRONIC_TEMPERATURE [K] 300

      &END SMEAR     

      &MIXING

          METHOD DIRECT_P_MIXING

          ALPHA   0.1

      &END

    &END SCF

      

    &POISSON

       PERIODIC XYZ

      &EWALD

        EWALD_TYPE SPME

        ALPHA  .64

        GMAX   21

        RCUT 5

      &END EWALD       

    &END

  &END DFT

  

  &SUBSYS

   &CELL

    PERIODIC XYZ

      A     13.9765253067         0.0000000000         0.0000000000

      B     0.0000000000        13.9765253067         0.0000000000

      C     0.0000000000         0.0000000000        13.9765253067

    &END CELL

   

    &COORD

Li            1.1647105      1.1647105      1.1647105

Li            1.1647105      1.1647105      5.8235526

Li            1.1647105      1.1647105     10.4823942

hut...@chem.uzh.ch

unread,
Dec 19, 2018, 3:41:06 AM12/19/18
to cp...@googlegroups.com
Hi

the parameter in the EWALD section are not very user friendly
(for historical reasons). In your case you should not keep
RCUT at a small value and change ALPHA.
It is better to use the default (RCUT calculated from EWALD_ACCURACY
and ALPHA internally).
Also you have to make sure that GCUT is big enough for your system
to give converged values.
With all these settings you should see the same behaviour as in DFTB+.

regards

Juerg Hutter
--------------------------------------------------------------
Juerg Hutter Phone : ++41 44 635 4491
Institut für Chemie C FAX : ++41 44 635 6838
Universität Zürich E-mail: hut...@chem.uzh.ch
Winterthurerstrasse 190
CH-8057 Zürich, Switzerland
---------------------------------------------------------------

-----cp...@googlegroups.com wrote: -----
To: "cp2k" <cp...@googlegroups.com>
From: "Wei Lai"
Sent by: cp...@googlegroups.com
Date: 12/19/2018 04:50AM
Subject: [CP2K:11061] comparing CP2K-DFTB (5.1) and DFTB+ (18.2)
--
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...@googlegroups.com.
To post to this group, send email to cp...@googlegroups.com.
Visit this group at https://groups.google.com/group/cp2k.
For more options, visit https://groups.google.com/d/optout.

Wei Lai

unread,
Dec 19, 2018, 9:51:19 AM12/19/18
to cp...@googlegroups.com
Dear Juerg,

Thanks for your suggestion.  Parameters I chose previously converged the results reasonably.  To be more systematic,  I tried the following combinations without specifying RCUT (I was doing that to make sure it's less than 1/2 of the box size).  Comparison of these with those I presented earlier still suggests strong sensitivity to ALPHA and difference from DFTB+.

Thanks, Wei

Accuracy   GMAX ALPHA      Li-Mulliken-charge H0-energy SCC-energy
1.00E-06     21 0.583             0.57183     -414.5978042 8.302909355
1.00E-10     21 0.583             0.57183     -414.5978042 8.302909355
1.00E-14     21 0.583             0.57183     -414.5978042 8.302909355
1.00E-14     61 0.583             0.57183     -414.5978033 8.302910247
1.00E-14   101 0.583             0.57183     -414.5978027 8.302910732
1.00E-14   101 0.35 (default)     0.572372     -414.6135268 8.288678932




You received this message because you are subscribed to a topic in the Google Groups "cp2k" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cp2k/RfYbOq3j0DM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cp2k+uns...@googlegroups.com.

Wei Lai

unread,
Dec 19, 2018, 1:10:01 PM12/19/18
to cp...@googlegroups.com
Dear Juerg,

I have done further testing and may be closer to find out the source of this discrepancy.  Basically, non-SCC results are "consistent" between CP2K and DFTB+.  Fore SCC-DFTB, they differ in whether to include SCC at the first scf (it also seems that DFTB+ applies non-scc scf first before applying SCC energy).  I don't know the coding thoughts of SCC well enough but I am wondering which one of these two is the better way.  Regarding why CP2K results are sensitive to ALPHA I guess there are many local energy minimums.

Thanks, Wei

CP2K:
Parameters Li-Mulliken-charge H0-energy SCC-energy
NonSCC full scf 0.737779     -417.18328600
SCC-1scf                 0.737779     -355.69044000 0
SCC-2scf                 0.720362     -361.83972460 0.137714872

DFTB+:
NonSCC full scf 0.737791      -417.18197790
SCC-1scf                 0.737791      -417.18197790 10.2841704
SCC-2scf                 0.711388      -417.10728727 9.561284596

Thomas Kühne

unread,
Dec 22, 2018, 9:31:55 AM12/22/18
to cp...@googlegroups.com
Dear Wei Lai, 

have you used explicit diagonalization or the default OT minimizer? 
Do the fully converged SCC-results agree? If not please provide the 
input file. 

Merry Christmas, 
Thomas
==============================
Thomas D. Kühne
Dynamics of Condensed Matter
Chair of Theoretical Chemistry
University of Paderborn
Warburger Str. 100
D-33098 Paderborn
Germany

Maxime Van den Bossche

unread,
Dec 22, 2018, 4:45:15 PM12/22/18
to cp2k
Hi all,

I also did a quick comparison now between CP2K and DFTB+
for a simple rocksalt MgO structure (8 atoms in total,
using the OT minimizer in CP2K). The input and output
files for both codes are attached.

What I found so far:

* Without periodicity, the two codes agree quite well
  in terms of the H0 and SCC energies (up to ~1e-4 Ha)
  as well as the Mulliken charges.

* In the periodic case, so far I haven't managed to
  get comparable results with the two codes. The CP2K
  results indeed appear sensitive to the choice of the
  Ewald alpha parameter, similar to what Wei observed.
  For each of the three ALPHA values I tried, the resulting
  energies and SCC charges are quite different from DFTB+.

* In contrast to Wei, though, I also get different results
  for both codes in non-self-consistent calculations
  (but at least here the CP2K results indeed no longer
  depend on ALPHA).

It would be great if you could check whether my CP2K
inputs have been appropriate. If so, I hope this example will
help to get to the bottom of this.

Best,
Maxime
files.zip

Thomas Kühne

unread,
Dec 24, 2018, 6:08:32 AM12/24/18
to cp...@googlegroups.com
Dear Maxime, 

your input files looks good to me. 
How large is the difference in the 
periodic cases? 

Merry Christmas, 
Thomas

--
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...@googlegroups.com.
To post to this group, send email to cp...@googlegroups.com.
Visit this group at https://groups.google.com/group/cp2k.
For more options, visit https://groups.google.com/d/optout.
<files.zip>

Wei Lai

unread,
Dec 24, 2018, 4:09:58 PM12/24/18
to cp...@googlegroups.com
With the intention to help with the discussion, I took the liberty to post the following numbers.

If I turn off “minimum image convention” or “mic” in qs_neighbor_lists.F (version 5.1; this was done automatically in version 6.1), the periodic nonscc results of cp2k are close to those from dftb+.

nonscc total energy:  -14.90396117681518 (cp2k) vs -14.9042897104 (dftb+).

Maxime was using 6.0 development version and the nonscc total energy was -15.00558399676375.

However, the difference in the periodic scc case became more dramatic:

core energy: -14.7017837002 (dftb+), -11.35591447406040 (cp2k, alpha=0.3), -13.03486875813706 (cp2k, alpha=0.5), -13.89182287767537 (Maxime, alpha=0.3)
scc energy:  1.2109415266 (dftb+), 2.94796400907580 (cp2k, alpha=0.3), 2.06305475569169 (cp2k, alpha=0.5), 0.07851968376930 (Maxime, alpha=0.3)

Thanks, Wei


You received this message because you are subscribed to a topic in the Google Groups "cp2k" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cp2k/RfYbOq3j0DM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cp2k+uns...@googlegroups.com.

Wei Lai

unread,
Jan 2, 2019, 12:53:56 PM1/2/19
to cp...@googlegroups.com
With my limited knowledge of fortran, I went through source codes of DFTB+ and cp2k and might have an idea for the difference in results.

First, the construction of H0, S, and gamma matrix seem to be consistent between two codes.  However, it seems they differ on how SCC (self-consistent charge) was applied.  In DFTB+, the self-consistent charge was the Mulliken charge on atoms.  In cp2k, it seems that H0, S, and gamma matrix was fed into KS-DFT framework so the self-consistent charge was the electron density in the real space.  Ideally this needs the basis functions which are not contained in skf files so perhaps some default Gaussian basis functions were used.  If the previous observation is correct, there seems to be an issue in the implementation of SCC-DFTB in cp2k. 

Thanks, Wei

hut...@chem.uzh.ch

unread,
Jan 11, 2019, 3:37:36 AM1/11/19
to cp...@googlegroups.com
Hi

I looked into these problems and I see that this behavior is
from a combination of bugs and hidden constraints on variables.

The bugs were introduced when the MIC was dropped after the implementation
of the k-point code. The Ewald parameters are partly set from the
input and partly set by using default values within the code.

To be on the save side I would suggest to only do DFTB calculations
with large enough computational cells. You can use
the MULTIPLE_UNIT_CELL keyword if you have a small cell.
&TOPOLOGY
MULTIPLE_UNIT_CELL ${NREP} ${NREP} ${NREP}
&END
&CELL
ABC 4.0 4.0 4.0
MULTIPLE_UNIT_CELL ${NREP} ${NREP} ${NREP}
&END CELL

I guess a cell with 10 Angstrom box length should be ok.

Use an ALPHA value that is 1 or larger and adjust GMAX for
your box size to get converged values.

I am working on fixes, they should be ready in the TRUNK version soon
and will be in the next release.

best regards

Juerg

--------------------------------------------------------------
Juerg Hutter Phone : ++41 44 635 4491
Institut für Chemie C FAX : ++41 44 635 6838
Universität Zürich E-mail: hut...@chem.uzh.ch
Winterthurerstrasse 190
CH-8057 Zürich, Switzerland
---------------------------------------------------------------

-----cp...@googlegroups.com wrote: -----
To: "cp2k" <cp...@googlegroups.com>
From: "Maxime Van den Bossche"
Sent by: cp...@googlegroups.com
Date: 12/22/2018 10:45PM
Subject: Re: [CP2K:11082] comparing CP2K-DFTB (5.1) and DFTB+ (18.2)
--
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...@googlegroups.com.
To post to this group, send email to cp...@googlegroups.com.
Visit this group at https://groups.google.com/group/cp2k.
For more options, visit https://groups.google.com/d/optout.


[attachment "files.zip" removed by Jürg Hutter/at/UZH]

Wei Lai

unread,
Jan 11, 2019, 10:13:03 AM1/11/19
to cp2k
Dear Juerg,

Thanks for the effort in looking into the problems.  In addition, I found that the real-space part of 1/R contribution to gmcharge was done with a neighbor list, while the gamma_matrix contribution to gmcharge was not.  In my opinion they should be treated in the same way (perhaps both a neighbor list).  I'd like to bring this up to your attention.  I look forward to the fixes!

Thanks, Wei

Wei Lai

unread,
Jan 14, 2019, 3:14:50 PM1/14/19
to cp2k
I tried the trunk version and results were updated.  Of course efforts have to made to converge Ewald energy but it appears that bugs have been fixed!

core energy: -14.7017837002 (dftb+), -14.68632501975257 (cp2k, alpha=0.5), -14.70135116830477 (cp2k, alpha=1)
scc energy:  1.2109415266 (dftb+), 1.23879325339532 (cp2k, alpha=0.5), 1.21153669321739 (cp2k, alpha=1)

Thanks, Wei
Reply all
Reply to author
Forward
0 new messages