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

DMITRII Drugov dresear... at gmail.com
Sun Dec 6 03:19:12 UTC 2020


Thank you a lot for this! I will update you with optimisation results, once 
it's done.

Regards,
Dmitrii

On Sunday, December 6, 2020 at 7:33:33 AM UTC+11 Travis wrote:

> Hi,
>
> Attached are prepared CIF files for bulk graphite with 4 layers. The 6x4x2 
> ortho cell has 384 atoms which seems to be the one you're working with. 
> Avogadro is not recommended for periodic systems (trying to open one of 
> these CIF files on my PC takes ages). It often messes up the structure by 
> either adding extra atoms or losing a few. I'd start with a cell 
> optimization of the bulk cell - these lattice parameters are from VASP. 
> Then you can implement slab boundaries and fix the bottom layer(s).
>
> -T
>
> On Saturday, December 5, 2020 at 12:50:55 AM UTC-5 dre... at gmail.com 
> wrote:
>
>> 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 <(904)%20501-4398>
>>      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/20201205/8025abd3/attachment.htm>


More information about the CP2K-user mailing list