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

[Teodoro Laino]

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.
>>>       
> >
>