[CP2K-user] [CP2K:5398] Re: graphite in CP2K

DMITRII Drugov dresear... at gmail.com
Sat Dec 5 05:50:55 UTC 2020


Hi guys, could you suggest the right cell setting for graphite simulation. 
Should I use extra space in xy dimension to get right optimised geometry? I 
build slab from Avogadro with 384 atoms  and xyz 17.04000000  14.75707288  
13.20000000 A. I froze two bottom layer and allowed remaining top two layer 
to equilibrate. 

I am using following parameters:
&GLOBAL
  PROJECT Graphite_geometry_optimization_moreMOs 
  RUN_TYPE GEO_OPT
  PRINT_LEVEL MEDIUM
&END GLOBAL
&FORCE_EVAL
  METHOD QS
  &DFT
    BASIS_SET_FILE_NAME BASIS_MOLOPT
    POTENTIAL_FILE_NAME GTH_POTENTIALS
    CHARGE 0
    MULTIPLICITY 1
    &MGRID
      CUTOFF 800
      NGRIDS 5
      REL_CUTOFF 70
    &END MGRID
    &QS
      EPS_DEFAULT 1.0E-12
      WF_INTERPOLATION ASPC
    &END QS
   &SCF
      SCF_GUESS ATOMIC
      EPS_SCF 1.0E-7
      MAX_SCF 1000
      CHOLESKY INVERSE
      ADDED_MOS 100
      &SMEAR ON
        METHOD FERMI_DIRAC
        ELECTRONIC_TEMPERATURE [K] 300
      &END SMEAR
      &DIAGONALIZATION
        ALGORITHM STANDARD
      &END DIAGONALIZATION
      &MIXING
        METHOD BROYDEN_MIXING
        ALPHA 0.4         
        NBROYDEN 8
      &END MIXING
    &END SCF
    &XC
      &XC_FUNCTIONAL
&PBE
&END PBE
      &END XC_FUNCTIONAL
      &vdW_POTENTIAL
    DISPERSION_FUNCTIONAL PAIR_POTENTIAL
    &PAIR_POTENTIAL
        PARAMETER_FILE_NAME dftd3.dat
        TYPE DFTD3
        REFERENCE_FUNCTIONAL PBE
        R_CUTOFF 15.0
    &END PAIR_POTENTIAL
     &END vdW_POTENTIAL
    &END XC
    &POISSON
      PERIODIC xy
      POISSON_SOLVER ANALYTIC
    &END POISSON
  &END DFT
  &SUBSYS
    &CELL
      ABC 18.46 13.53 50.0
      ALPHA_BETA_GAMMA 90.0 90.0 120.0
      PERIODIC xy
    &END CELL
    &COORD
      C    0.00000000   0.00000000   0.00000000
      ...
      C   17.75000000  13.52731681   9.90000000
    &END COORD
    &KIND C
      BASIS_SET DZVP-MOLOPT-GTH
      POTENTIAL GTH-PBE-q4
    &END KIND
   &END SUBSYS
&END FORCE_EVAL
&MOTION
  &CONSTRAINT
    &FIXED_ATOMS
     COMPONENTS_TO_FIX XYZ
     LIST 1..194
    &END FIXED_ATOMS
  &END CONSTRAINT
  &GEO_OPT
  OPTIMIZER LBFGS
  MAX_ITER 300
  &END GEO_OPT
  &END MOTION

I spend 34 hours with 36 CPU and 120 GB of memory and still didn't 
optimised it yet. It seems that energy does not decrease much. 
     384
 i =        1, E =     -2025.9045014398
     384
 i =        6, E =     -2075.1262328870
 If I change cell parameters to 
  &SUBSYS
    &CELL
      ABC 18.46 13.53 50.0
      PERIODIC xy
      SYMMETRY ORTHORHOMBIC
    &END CELL
     384
 i =        1, E =     -2132.8940479508
     384
 i =       11, E =     -2146.1458464543

It does not help much.

Regards,
Dmitrii

On Friday, December 4, 2020 at 2:52:34 PM UTC+11 DMITRII Drugov wrote:

> Thank you for your reply! I am still running optimisation, I will share 
> update once its done.
>
> Regards,
> Dmitrii
>
> On Thursday, December 3, 2020 at 1:10:48 PM UTC+11 Travis wrote:
>
>> Hi,
>>
>> Graphite unit cell is hexagonal (
>> https://materialsproject.org/materials/mp-48/). You can orthogonalize 
>> any cell though. Do it by hand or use a program like atomsk (
>> https://atomsk.univ-lille.fr/),
>>
>> atomsk foo.cif -orthogonal-cell bar.cif
>>
>> -T
>>
>> On Wednesday, December 2, 2020 at 6:38:50 PM UTC-5 dre... at gmail.com 
>> wrote:
>>
>>> Good day dear CP2K users, do you think its right to use  90 90 90 
>>> orthorhombic symmetry for Graphite cell?
>>> Should it be hexagonal 90 90 120 alpha betta gamma?
>>>
>>> Regrads,
>>> Dmitrii 
>>>
>>> On Thursday, May 29, 2014 at 8:01:13 PM UTC+10 mic... at gmail.com 
>>> wrote:
>>>
>>>> Thanks for the clarification, Matthias. 
>>>>
>>>>    I must admit that as someone who started off with PWs it is quite 
>>>> surprising to see that changing basis set within the same "class of 
>>>> complexity" can mess up things to the point of not being able to converge 
>>>> the SCF. In the future I'll pay more attention to testing the basis set 
>>>> when using CP2K, and take due note that there is much more than the number 
>>>> of polarization functions to define the quality of the basis!
>>>>
>>>> Best wishes,
>>>> Michele
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, May 29, 2014 at 9:17 AM, Matthias Krack <mat... at psi.ch> 
>>>> wrote:
>>>>
>>>>> Dear Michele,
>>>>>
>>>>> I would not consider graphite as a specifically nasty system. As Matt 
>>>>> already wrote, the basis sets in GTH_BASIS_SETS resulted from atomic 
>>>>> calculations using the actual GTH pseudopotential. Such an atomic basis set 
>>>>> optimisation gives in the case of carbon only a set of exponents and 
>>>>> contraction coefficients for a 2s and 2p function. The SZV (single-valence) 
>>>>> basis sets in GTH_BASIS_SETS are the results of such optimisations. You may 
>>>>> try the C SZV basis set and you will see that is behaves at least 
>>>>> reasonably for your system (you may also add a prmitive d polarisation 
>>>>> function -> SZVP)  However, experience has shown that such a minimal basis 
>>>>> set is by far not accurate enough in most cases as it does not provide 
>>>>> sufficient flexibility. Thus it is not suited for production runs. The 
>>>>> double-zeta (DZV) GTH basis sets are derived from the corresponding SZV 
>>>>> basis sets just by using the smallest exponent as a primitive function for 
>>>>> the second valence function. This exponent is often rather small which 
>>>>> results in a quite diffuse valence function without any nodal structure. 
>>>>> These DZV basis sets were tested in molecular calculations in which they 
>>>>> worked. You see, however, that the procedure is not based on any strict 
>>>>> optimisation method. This deficiency may become apparent for condensed 
>>>>> phase systems like your system. For such systems I would always recommend 
>>>>> the use of the MOLOPT SR basis sets as already suggested which provide 
>>>>> results closer to PW calculations. The generation procedure of the MOLOPT 
>>>>> basis sets performs an optimisation of the contraction coefficients of all 
>>>>> included valence functions. In this respect the MOLOPT SR basis sets can be 
>>>>> considered as a kind of "second generation" CP2K basis sets.
>>>>> Nevertheless, I would like to note that there are many cases in which 
>>>>> the GTH_BASIS_SETS work fine and their use may become beneficial as they 
>>>>> are computionally less demanding. I know that these basis set issues are 
>>>>> quite annoying, especially for people coming from the PW community.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Matthias
>>>>>
>>>>>
>>>>> On Wednesday, May 28, 2014 9:57:05 PM UTC+2, Michele Ceriotti wrote:
>>>>>
>>>>>> Dear Matt (and Marcella who basically replied the same in private),
>>>>>>
>>>>>>    Thanks a million, using the molopt basis set does fix things. I 
>>>>>> had tried both the dzvp from basis_sets and gth_basis_set, and I was 
>>>>>> getting similar nonsense.
>>>>>>
>>>>>> I am a bit scared seeing how much difference it makes changing the 
>>>>>> basis set. Any idea why graphite should be such a nasty beast? I had 
>>>>>> experimented with different basis sets for water and never saw such a 
>>>>>> dramatic effect.
>>>>>>
>>>>>> All the best,
>>>>>> Michele
>>>>>> On 28 May 2014 19:23, "Matt W" <Mat... at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Michele,
>>>>>>>
>>>>>>> please try using the MOLOPT basis sets provided with CP2K 
>>>>>>> ($CP2K_root/tests/QS/BASIS_MOLOPT) that prehaps give a more 
>>>>>>> suitable starting point for describing a "molecular" system like graphite 
>>>>>>> than atomic optimization based ones.
>>>>>>>
>>>>>>> Using a DZVP-MOLOPT-SR-GTH basis - I get SCF convergence in ~10 
>>>>>>> cycles and geometry converges in ~10 steps (with BFGS).
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> On Wednesday, May 28, 2014 5:19:30 PM UTC+1, Michele Ceriotti wrote:
>>>>>>>>
>>>>>>>> Hi Matthias, 
>>>>>>>>    Thanks for the quick answer. I have already played with the 
>>>>>>>> obvious parameters, point is it is impossible to converge the scf properly. 
>>>>>>>> Everything looks like what you get when the geometry is crazy, and 
>>>>>>>> indeed my student tried to enlarge the cell (by almost 10%!) and got  
>>>>>>>> converged scf and more reasonable forces. 
>>>>>>>> However this is inconsistent with the literature and the results 
>>>>>>>> from siesta.
>>>>>>>> We have been trying to fiddle with the scf parameters for days, but 
>>>>>>>> get consistently 100au forces on a geometry that should be very close to 
>>>>>>>> optimum.
>>>>>>>> Do you see something wrong with how we define the cell or the 
>>>>>>>> positions?
>>>>>>>> Best
>>>>>>>> Michele
>>>>>>>> On 28 May 2014 17:47, "Matthias Krack" <mat... at psi.ch> wrote:
>>>>>>>>
>>>>>>>>> Hi Michele,
>>>>>>>>>
>>>>>>>>> I would suggest to set EPS_DEFAULT in @QS section at least to 
>>>>>>>>> 1.0E-12 or lower and for the ALPHA in &MIXING I would also use a smaller 
>>>>>>>>> value like 0.2. Maybe this will help to converge your system properly.
>>>>>>>>>
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>> On Wednesday, May 28, 2014 4:20:44 PM UTC+2, Michele Ceriotti 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Dear CP2K community, 
>>>>>>>>>>
>>>>>>>>>>      I have been trying for a few days to set up calculations of 
>>>>>>>>>> graphite as an exercise for a student but I am getting the weirdest 
>>>>>>>>>> results.  I am sure in the it will end up being a silly mistake in the 
>>>>>>>>>> input, but I can't get to see it so perhaps someone can help. 
>>>>>>>>>>
>>>>>>>>>> Despite using a fairly large FD smearing, the SCF cycle has a 
>>>>>>>>>> hard time converging, and when the maximum number of steps is reached 
>>>>>>>>>>
>>>>>>>>>>     50 Broy./Diag. 0.50E+00    1.2     0.00014351      
>>>>>>>>>> -819.2909959720 -2.28E-09
>>>>>>>>>>   *** SCF run NOT converged ***
>>>>>>>>>>
>>>>>>>>>> and the calculation carries on with what it has got, diagnostics 
>>>>>>>>>> are really strange. 
>>>>>>>>>>
>>>>>>>>>> For a start, eigenvalues show two weird very low-energy states
>>>>>>>>>>  MO EIGENVALUES AND MO OCCUPATION NUMBERS
>>>>>>>>>> # MO index          MO eigenvalue [a.u.]            MO occupation
>>>>>>>>>>          1                    -21.523076                 2.000000
>>>>>>>>>>          2                    -21.517160                 2.000000
>>>>>>>>>>          3                     -1.383548                 2.000000
>>>>>>>>>>          4                     -0.510418                 2.000000
>>>>>>>>>>
>>>>>>>>>> forces on the atoms are insane
>>>>>>>>>>  ATOMIC FORCES in [a.u.]
>>>>>>>>>>  # Atom   Kind   Element          X              Y              Z
>>>>>>>>>>       1      1      C           4.68736611     4.63921800  
>>>>>>>>>> -222.86999309
>>>>>>>>>>       2      1      C          -1.57720920    -4.48651652   
>>>>>>>>>> 124.33822840
>>>>>>>>>>       3      1      C          -5.01734639     3.10518104   
>>>>>>>>>> 176.16292919
>>>>>>>>>>
>>>>>>>>>> and so is the stress tensor
>>>>>>>>>>  STRESS TENSOR [GPa]
>>>>>>>>>>             X               Y               Z
>>>>>>>>>>   X   -8233.84728056      8.05482610      0.90481573
>>>>>>>>>>   Y       8.05482610  -9552.76932222     -0.49445437
>>>>>>>>>>   Z       0.90481573     -0.49445437  -2526.59040628
>>>>>>>>>>
>>>>>>>>>> I was thinking of an error in the structure or the cell 
>>>>>>>>>> parameters, but I checked it many times and everything seems in order. The 
>>>>>>>>>> same structure, with same functional and similar parameters in SIESTA 
>>>>>>>>>> converges like a stone, and gives no problem whatsoever. 
>>>>>>>>>>  
>>>>>>>>>> Can you spot something obvious that I am missing? I'd really like 
>>>>>>>>>> to use CP2K for this exercise, but I can't seem to figure out what is going 
>>>>>>>>>> wrong. 
>>>>>>>>>>
>>>>>>>>>> Many thanks,
>>>>>>>>>> Michele
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>> 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/koy91UtxlQw/unsubscribe.
>>>>>>>>> To unsubscribe from this group and all its topics, send an email 
>>>>>>>>> to cp... at googlegroups.com.
>>>>>>>>> To post to this group, send email to c... at googlegroups.com.
>>>>>>>>> Visit this group at http://groups.google.com/group/cp2k.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>> -- 
>>>>>>> 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/koy91UtxlQw/unsubscribe.
>>>>>>> To unsubscribe from this group and all its topics, send an email to 
>>>>>>> cp... at googlegroups.com.
>>>>>>> To post to this group, send email to c... at googlegroups.com.
>>>>>>> Visit this group at http://groups.google.com/group/cp2k.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>> -- 
>>>>> 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/koy91UtxlQw/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to 
>>>>> cp... at googlegroups.com.
>>>>> To post to this group, send email to c... at googlegroups.com.
>>>>> Visit this group at http://groups.google.com/group/cp2k.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20201204/79036896/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-12-05 at 4.49.27 pm.png
Type: image/png
Size: 410640 bytes
Desc: not available
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20201204/79036896/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-12-05 at 4.49.27 pm.png
Type: image/png
Size: 410640 bytes
Desc: not available
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20201204/79036896/attachment-0001.png>


More information about the CP2K-user mailing list