[gpaw-users] GPAW calculation crashes with adsorbates on jellium of certain geometries

[Rasmus Karlsson]

I made some further progress: https://gitlab.com/gpaw/gpaw/issues/7

Apparently, as soon as an atom is added to the system, the
initialization entails distributing the electrons over the
projector functions (?) of the atom. For H, this means that the
maximum number of electrons allowed in the slab is 9, because H as 1 s,
2s and 2p projector functions available in its setup.

Rasmus

Rasmus Karlsson writes:

> Dear Mikkel,
> thank you for your reply. I can certainly do the calculations in grid
> mode, but considering how much faster PW mode is, it would be a nice feature if it would be mode-agnostic. Is it difficult to get it to
> work in PW mode? Still, the userbase for
> jellium is perhaps too limited for that to be interesting. In any case,
> we should look at adding an assertion that checks that the calculation
> is running in grid mode and not in PW mode.
>
> However, I actually found something else related to jellium calculations that is
> strange (explaining the new title of this thread). I'm attaching the script that I'm looking
> at. Apparently, if you combine the dimensions of the slab, the
> Wigner-Seitz radius and the adsorbate identity in an unfortunate way, the code crashes.
>
> If you set the flag use_higher_b to True (making the slab bigger), the code will crash for H, He,
> Li and Be (but not B or C, see below) with the
> following error:
>
> "
>     correct_for_charge(f_j, charge, degeneracy_j, True)
>   File "/Users/rasmusk/Library/Python/2.7/lib/python/site-packages/gpaw/setup.py", line 142, in correct_for_charge
>     if charge >= 0:
> RuntimeError: maximum recursion depth exceeded in cmp
> Uncaught exception. Entering post mortem debugging
> Running 'cont' or 'step' will restart the program
>> /Users/rasmusk/Library/Python/2.7/lib/python/site-packages/gpaw/setup.py(142)correct_for_charge()
> -> if charge >= 0:
> "
>
> However, if you either use a lower b ("use_higher_b = False", lowering
> the number of electrons in each cell since the slab is smaller) or use a higher wigner-seitz radius
> ("use_higher_rs = True", also reducing number of electrons in the slab
> in each cell), the code works. Strangely,
> if a heavier adsorbate is used (B or C in the attached example code), the
> code also runs. The error does not seem to be related to whether or not
> the dimensions of the jellium slab are evenly divisible with the grid spacing
> (since setting use_dimensions_evenly_divisible_w_h to either True or
> False has no effect on the error).
>
> This error message was apparently encountered by someone before (https://listserv.fysik.dtu.dk/pipermail/gpaw-users/2012-July/001635.html)
> but that was not related to a jellium calculation. I guess this points
> to some kind of issue in how GPAW handles certain (small?) initial
> electronic densities. 
>
> Thanks,
> Rasmus
>
>
> Mikkel Strange writes:
>
>> Dear Rasmus,
>>
>> thanks for pointing this out.
>> I'm afraid that GPAW can only do grid mode calculations for jellium systems (except for bulk system where plane wave mode should also work). 
>> I think the reason why it does not work in PW mode is that it "throws away"  the  density profile specified in the 
>> JelliumSurfacePoissonSolver.
>>
>> Can you do the calculations in grid mode, or do you need the PW basis?
>>
>> In any case, at least an error message when trying to use PW would nice :-)


-- 
Rasmus Karlsson, PhD