[gpaw-users] GPAW PW crashes if ecut is too high

[Jens Jørgen Mortensen]

Den 02-09-2013 20:21, Rasmus Karlsson skrev:
> Hi Marcin!
>
> I see... Do you know of any way to get around this problem that does 
> not require me to set really low grid spacings (I had to go to h=0.10 
> Å, which will probably be quite time consuming)? The problem is of 
> course that I want the ability to optimize cell size and atomic 
> positions at the same time, which is hard to manage without 
> UnitCellFilter. I could of course just scale the volume of the cell to 
> a couple of point and fit an EOS, but for this system I'm not sure the 
> cell angles will stay exactly the same after relaxation. I guess the 
> problem lies in how GPAW creates its grids in these kinds of cells, so 
> it's not a matter of using some other ASE optimizer instead?
>
> In any case, if the only solution is running with h=0.10 Å, that's 
> what I'll do.

The best solution right now is to choose the unit cell vectors so that 
the angles between them are closer to 90 degrees - that would cure the 
problem (choose the third axis as a1+a3 or something like that).

Ideally, GPAW should be able to handle such strange cells, but I will 
not have time to fix it right now.  Let me know If anyone wants to dig 
into the PW code and help fix the problem.

Jens Jørgen


>
> Thanks!
>
> Rasmus
>
> On 09/02/2013 12:58 AM, Marcin Dulak wrote:
>> Hi,
>>
>> On 09/01/2013 12:26 AM, Rasmus Karlsson wrote:
>>> Hi!
>>> I just tried starting a PW calculation for relaxation of a unit cell 
>>> of CmC2_1 space group. However, GPAW immediately crashes with
>>> ../gpaw/wavefunctions/pw.py", line 37, in __init__
>>>     assert ((gd.h_cv**2).sum(1) <= 0.5 * pi**2 / ecut).all()
>> this is a known problem with skewed cells:
>> https://listserv.fysik.dtu.dk/pipermail/gpaw-developers/2012-May/002870.html 
>>
>> You need to set h manually (in addition to PW) to a very small value.
>>
>> Best regards,
>>
>> Marcin
>>>
>>> If running through with pdb, (gd.h_cv**2).sum(1) is
>>> array([ 0.05550866,  0.25919729,  0.25919729])
>>> and
>>> 0.5*pi**2/ecut is
>>> 0.22380475860123122
>>> Obviously, the second and third item in the array is too big. 
>>> Reducing the cutoff from 600 eV to 500 eV makes it work. This is 
>>> somewhat strange.
>>>
>>> gd.h_cv is
>>> array([[  2.35602765e-01,   0.00000000e+00,   0.00000000e+00],
>>>        [  3.11742550e-17,   5.09114220e-01,   0.00000000e+00],
>>>        [  3.11742550e-17,  -4.50356897e-01, 2.37436210e-01]])
>>>
>>> Can anyone comment on what is going on? Am I doing something wrong, 
>>> or is GPAW behaving strangely?
>>>
>>> The calculation was run with v. 0.9.1.10258
>>>
>>> Thanks,
>>> Rasmus
>>>
>>
>>
>