[CP2K:2257] Re: Bug in the cell-optimization

Laino Teodoro teodor... at gmail.com
Tue Sep 8 02:09:35 CEST 2009


Roman,

Sorry about the delay, but that's unfortunately unavoidable when  
reports are done in a misleading manner..
I checked better and there was indeed a bug but it had nothing to do  
with cell-optimization.
It was entirely located in the multiple_unit_cell option.

It is now fixed in the CVS. Thanks for reporting this issue and  
remember next time to provide all details (this should be a good  
practice every time one shouts for help or claims to have found a bug  
in whatever mailing list (not necessarily just in this one)).

Teo

On 7 Sep 2009, at 15:30, xujroman wrote:

>
> Dear Teo,
>
> Thank you very much for your quick response.
> I have to apologize for the uncomplete description of the problem.
> And you are complete right that the CP2K-code performes the coordinate
> transformation correctly with the multiple_uni_cell option. However,
> with the multiple_unit_cell option this is not the case. Here is my
> complete example inputfile:
>
> &FORCE_EVAL
>   METHOD Quickstep
>   STRESS_TENSOR ANALYTICAL
>   &DFT
>     &MGRID
>       CUTOFF 400
>     &END MGRID
>     &QS
>       WF_INTERPOLATION PS
>       EXTRAPOLATION_ORDER 3
>     &END QS
>     &SCF
>       SCF_GUESS ATOMIC
>       MAX_SCF 500
>       &OT
>         PRECONDITIONER FULL_ALL
>       &END OT
>     &END SCF
>     &XC
>       &XC_FUNCTIONAL Pade
>       &END XC_FUNCTIONAL
>     &END XC
>   &END DFT
>   &SUBSYS
>     &CELL
>        MULTIPLE_UNIT_CELL 2 2 2
>        PERIODIC XYZ
>          A 2.7 0.0 2.7
>          B 0.0 2.7 2.7
>          C 2.7 2.7 0.0
>     &END CELL
>     &TOPOLOGY
>        MULTIPLE_UNIT_CELL 2 2 2
>     &END TOPOLOGY
>     &COORD
>     Si                   0.00 0.00 0.00
>     Si                   1.35 1.35 1.35
>     &END COORD
>     &KIND Si
>       BASIS_SET DZVP-MOLOPT-SR-GTH
>       POTENTIAL GTH-PADE-q4
>     &END KIND
>   &END SUBSYS
> &END FORCE_EVAL
> &GLOBAL
>   PROJECT Bulk_Si
>   RUN_TYPE CELL_OPT
>   PRINT_LEVEL MEDIUM
> &END GLOBAL
> &MOTION
>   &CELL_OPT
>     OPTIMIZER CG
>     KEEP_ANGLES .TRUE.
>     &CG
>       &LINE_SEARCH
>         TYPE 2PNT
>       &END LINE_SEARCH
>     &END CG
>   &END CELL_OPT
>   &GEO_OPT
>   OPTIMIZER CG
>    &CG
>      &LINE_SEARCH
>        TYPE 2PNT
>      &END LINE_SEARCH
>    &END CG
>   &END GEO_OPT
> &END MOTION
>
>
> Than CP2K produces the following restart file for the first geometry
> optimization:
>
> "Bulk_Si-GEO_OPT-0-1.restart"
>
> &GLOBAL
>    PRINT_LEVEL  MEDIUM
>    PROJECT_NAME Bulk_Si-GEO_OPT-0
>    RUN_TYPE  GEO_OPT
>  &END GLOBAL
>  &MOTION
>    &GEO_OPT
>      OPTIMIZER  CG
>      STEP_START_VAL               4
>      &CG
>        &LINE_SEARCH
>          TYPE  2PNT
>        &END LINE_SEARCH
>      &END CG
>    &END GEO_OPT
>    &CELL_OPT
>      OPTIMIZER  CG
>      KEEP_ANGLES  T
>      &CG
>        &LINE_SEARCH
>          TYPE  2PNT
>        &END LINE_SEARCH
>      &END CG
>    &END CELL_OPT
>  &END MOTION
>  &FORCE_EVAL
>    METHOD  QS
>    STRESS_TENSOR  ANALYTICAL
>    &DFT
>      &SCF
>        MAX_SCF             500
>        SCF_GUESS  ATOMIC
>        &OT  T
>          PRECONDITIONER  FULL_ALL
>        &END OT
>      &END SCF
>      &QS
>        EXTRAPOLATION  PS
>        EXTRAPOLATION_ORDER               3
>      &END QS
>      &MGRID
>        CUTOFF     4.0000000000000000E+02
>      &END MGRID
>      &XC
>        DENSITY_CUTOFF     1.0000000000000000E-10
>        GRADIENT_CUTOFF     1.0000000000000000E-10
>        TAU_CUTOFF     1.0000000000000000E-10
>        &XC_FUNCTIONAL  NO_SHORTCUT
>          &PADE  T
>          &END PADE
>        &END XC_FUNCTIONAL
>      &END XC
>    &END DFT
>    &SUBSYS
>      &CELL
>        A     7.6367532368147142E+00    0.0000000000000000E+00
> 0.0000000000000000E+00
>        B     3.8183766184073580E+00    6.6136223055145820E+00
> 0.0000000000000000E+00
>        C     3.8183766184073580E+00    2.2045407685048608E+00
> 6.2353829072479581E+00
>        PERIODIC  XYZ
>        MULTIPLE_UNIT_CELL               1              1
> 1
>      &END CELL
>      &COORD
> Si    3.0639514919983863E-02   -2.8242821460592239E-02
> 1.2131623166612593E-01
> Si    1.3193495751433768E+00    1.3782624207317524E+00
> 1.2286957353427554E+00
> Si    3.8490798181990464E+00   -2.8320697084029275E-02
> 1.2126783349051763E-01
> Si    5.1376820476818041E+00    1.3783083847899655E+00
> 1.2287240811324363E+00
> Si    1.9398877629734372E+00    3.2785123111400014E+00
> 1.2127224020316246E-01
> Si    3.2284938259833087E+00    4.6851396455951750E+00
> 1.2287292059456105E+00
> Si    5.7582126739877406E+00    3.2785351488380750E+00
> 1.2131193923098339E-01
> Si    7.0469084002716542E+00    4.6850408392785452E+00
> 1.2286951015890237E+00
> Si    1.9398313145352879E+00    1.0740001965920085E+00
> 3.2390111451643167E+00
> Si    3.2285203779859857E+00    2.4805201365770992E+00
> 4.3463762721786576E+00
> Si    5.7582729781511999E+00    1.0739700719830776E+00
> 3.2389492368130282E+00
> Si    7.0468843476696410E+00    2.4805953782967070E+00
> 4.3464148788581944E+00
> Si    3.8490558773340240E+00    4.3807727795452909E+00
> 3.2389587712566126E+00
> Si    5.1376813917952999E+00    5.7873852648962050E+00
> 4.3464231864196980E+00
> Si    7.6674155348390309E+00    4.3808259988106144E+00
> 3.2390115121197063E+00
> Si    8.9561123418762545E+00    5.7873380179790690E+00
> 4.3463760808472580E+00
>        UNIT angstrom
>        SCALED  F
>      &END COORD
>      &KIND Si
>        BASIS_SET DZVP-MOLOPT-SR-GTH
>        POTENTIAL GTH-PADE-q4
>        &BASIS
>  1
>  2 0 2 4 2 2 1
>   0.1256767641387000E+01  0.2277184666000000E+00 -0.1025748084300000E
> +01  0.6777626750000000E-01  0.9978562
> 880000000E-01  0.1590266803000000E+00
>   0.5063941224780000E+00 -0.2432359930000000E-01  0.6942830333000000E
> +00 -0.2137167702000000E+00 -0.4119852
> 298000000E+00  0.3923304368000000E+00
>   0.2388838456620000E+00 -0.5586397789000001E+00
> 0.5816256160000000E-01 -0.4098937266000000E+00 -0.5718312
> 630000000E-01  0.3930851518000000E+00
>   0.8733688383600000E-01 -0.2072725022000000E+00 -0.2581810090000000E
> +00 -0.3539223027000000E+00  0.7003078
> 694000000E+00  0.5503371190000000E+00
>          # Basis set name:  DZVP-MOLOPT-SR-GTH  for symbol:  SI
>          # Basis set read from the basis set filename: BASIS_SET
>        &END BASIS
>        &POTENTIAL
>  2 2
>   0.4400000000000000E+00 1 -0.7336102970000000E+01
>  2
>   0.4227381300000000E+00 2  0.5906928310000000E+01  
> -0.1261893970000000E
> +01
>   0.3258196220000000E+01
>   0.4842784200000000E+00 1  0.2727013460000000E+01
>          # Potential name:  GTH-PADE-Q4  for symbol:  SI
>          # Potential read from the potential filename: POTENTIAL
>        &END POTENTIAL
>      &END KIND
>      &TOPOLOGY
>        MULTIPLE_UNIT_CELL               1              1
> 1
>      &END TOPOLOGY
>    &END SUBSYS
>  &END FORCE_EVAL
>
>
> Unfortunately the coordinates of the Si atoms are not correct with
> respect to the transformed unit cell vectors A, B, and C. The correct
> coordinates should look like this:
>
>
> Si   -1.0974014519825657E-04   -1.7676012019053982E-03
> -1.2247900828984469E-04
> Si    1.9088000735955255E+00    1.0944726640717317E+00
> 7.7893023499684144E-01
> Si    3.8183059956121781E+00   -1.7779368613748551E-03
> -1.1357811744934891E-04
> Si    5.7271759294263447E+00    1.0944547185135503E+00
> 7.7890654502406864E-01
> Si    1.9090749183411335E+00    3.3050573189720218E+00
> -1.5157491350578401E-04
> Si    3.8179628211673160E+00    4.4012778324505941E+00
> 7.7892967187829554E-01
> Si    5.7274934267539006E+00    3.3050361130777244E+00
> -1.3821143796487556E-04
> Si    7.6363617347003778E+00    4.4012824684472971E+00
> 7.7891991655355786E-01
> Si    1.9091055301673019E+00    1.1005059638846280E+00
> 3.1175911749541818E+00
> Si    3.8179649967213978E+00    2.1967404071085168E+00
> 3.8966155940247806E+00
> Si    5.7274452451871918E+00    1.1005178548571481E+00
> 3.1175479694808246E+00
> Si    7.6363591558557724E+00    2.1967134353509921E+00
> 3.8966375352308700E+00
> Si    3.8182995220292710E+00    4.4073191096446083E+00
> 3.1175900344650893E+00
> Si    5.7271689960387739E+00    5.5035538456743192E+00
> 3.8966033344321609E+00
> Si    7.6366707112344292E+00    4.4073206445445692E+00
> 3.1175597801613035E+00
> Si    9.5455465773110539E+00    5.5035454488461228E+00
> 3.8966256806012440E+00
>
>
> Regarsds,
> Roman
>
>
>
>
>
>
>
> On 7 Sep., 12:32, Teodoro Laino <teodor... at gmail.com> wrote:
>> Roman,
>>
>> there is a bunch of missing information. The CELL_UC is printed only
>> when you use multiple_unit_cell, which is by
>> far not he default.
>> Is this maybe the case? Are you using multiple_unit_cell option?  If
>> yes.. don't you think that maybe this could be an important thing  
>> to say ?
>> What is the reason why all the time people are measuring out  
>> carefully
>> information from their input file?
>> Why not sending directly the input?
>>
>> Just to make the point of the situation clear enough:
>> - without multiple_unit_cell there are no bugs (optimization is
>> completed in 5 steps)
>> - I checked as well the multiple_unit_cell and there are no bugs  
>> (your
>> coordinates works perfectly) (optimization is completed in 11  
>> steps with
>> a  2 2 2 repetition).
>>
>> since I have no idea why have CELL_UC in your output file, I  
>> cannot say
>> anything else than just confirming that the coordinates are properly
>> adapted to the rotation of the cell and there is no evidence for  
>> bugs.
>> (Keep in mind that the major printing of the coordinates that look  
>> like
>> the thing you've pasted in the message is done long time before the
>> rotation of the matrix).
>>
>> If you still want to claim to have found a bug please attach a  
>> complete
>> input file.
>> A code updated to the lastest CVS version may help as well the
>> communication in order to avoid to see different things.
>>
>> Regards,
>> Teo
>>
>> xujroman wrote:
>>> Dear Teo,
>>
>>> the following part of the input file ndescribes my unit cell:
>>
>>>    &CELL
>>>        PERIODIC XYZ
>>>          A 2.7 0.0 2.7
>>>          B 0.0 2.7 2.7
>>>          C 2.7 2.7 0.0
>>>     &END CELL
>>>     &TOPOLOGY
>>>     &END TOPOLOGY
>>>     &COORD
>>>     Si                   0.00 0.00 0.00
>>>     Si                   1.35 1.35 1.35
>>>     &END COORD
>>
>>> Than CP2K performes a coordinat transformation:
>>
>>>  CELL_UC| Volume
>>> [angstrom^3]:                                            39.366
>>>  CELL_UC| Vector a [angstrom]     3.818     0.000     0.000    |a|
>>> =       3.818
>>>  CELL_UC| Vector b [angstrom]     1.909     3.307     0.000    |b|
>>> =       3.818
>>>  CELL_UC| Vector c [angstrom]     1.909     1.102     3.118    |c|
>>> =       3.818
>>>  CELL_UC| Angle (b,c), alpha
>>> [degree]:                                    60.000
>>>  CELL_UC| Angle (a,c), beta
>>> [degree]:                                    60.000
>>>  CELL_UC| Angle (a,b), gamma [degree]:
>>> 60.000
>>
>>> However the Si coordinates remain at the positions:
>>
>>>      1    1   Si   14    0.000000    0.000000    0.000000
>>> 4.00      28.0860
>>>      2    1   Si   14    1.350000    1.350000    0.350000
>>> 4.00      28.0860
>>
>>> And this is of course not correct, because the periodic images  
>>> are now
>>> arranged in a wong way.
>>
>>> Regards,
>>> Roman
>>
>>> On 7 Sep., 11:50, Teodoro Laino <teodor... at gmail.com> wrote:
>>
>>>> Dear Xujroman,
>>
>>>> what do you call "atomar basis". When the cell is rotated and  
>>>> aligned
>>>> along the X,Y and Z axis the atomic coordinates are too...
>>>> I don't see any evidence for the bug you're claiming to have found.
>>
>>>> Of course fee free to attach an input file that reproduces this  
>>>> error.
>>>> Regards,
>>>> Teo
>>
>>>> xujroman wrote:
>>
>>>>> Dear CP2K users,
>>
>>>>> I am performing a cell optimization using Cell_Opt and Geo_Opt for
>>>>> bulk Si.
>>>>> However, I recognized a bug during the setup of the unit cell.
>>
>>>>> If the starting cell vectors are given along arbitrary directions,
>>>>> CP2K performes a coodinate transformation so that the first cell
>>>>> vector (A) points along the x-axis. However, the atomar basis  
>>>>> in the
>>>>> unit cell is not transformed. That leads to a completely different
>>>>> (wrong) atomic structure taking the periodic boundary  
>>>>> conditions into
>>>>> account.
>>
>>>>> The most simple way to avoid this bug, is to use cell vectors  
>>>>> in such
>>>>> a way that the A vector is parallel to the x-axis.
> >




More information about the CP2K-user mailing list