[CP2K:2257] Re: Bug in the cell-optimization
Laino Teodoro
teodor... at gmail.com
Tue Sep 8 00:09:35 UTC 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