[gpaw-users] Transport calculation--atom "too close to boundary"

[jingzhe Chen]

At least you should set 1 for the transport direction,  if you have enough
vacuum space in the other two directions.
It is not periodic, you are right, setting it True is just to bypass the the
raising error you reported. In the code,
it is solved in fixed boundary condition.

Best.
Jingzhe

2011/10/18 Alex Eftimiades <alexeftimiades at gmail.com>

> My system's pbc was not (1,1,1). I did not know that was necessary. Why
> does the entire system need to have a pbc of (1,1,1)? The leads should be
> the only component with periodicity--and that should only have to be applied
> along the direction of transport (namely, the z axis.)
>
> Thanks,
> Alex
>
> On Tue, Oct 18, 2011 at 10:39 AM, jingzhe Chen <jingzhe.chen at gmail.com>wrote:
>
>> Hi,
>>
>>        One possibility is that your system's pbc is not (1,1,1), change to
>> (1,1,1)
>> and retry.
>>
>>        Best.
>>        Jingzhe
>>
>>
>>
>> 2011/10/18 Alex Eftimiades <alexeftimiades at gmail.com>
>>
>>> While doing a transport calculation with gpaw, I keep getting the
>>> following error message:
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "/media/8051-29A1/nanotube_transport2.py", line 75, in <module>
>>>     t.calculate_iv()
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/transport/calculator.py",
>>> line 2292, in calculate_iv
>>>     self.negf_prepare()
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/transport/calculator.py",
>>> line 986, in negf_prepare
>>>     self.initialize_transport()
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/transport/calculator.py",
>>> line 306, in initialize_transport
>>>     calc.set_positions(atoms)
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/paw.py", line 301, in
>>> set_positions
>>>     spos_ac = self.initialize_positions(atoms)
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/paw.py", line 294, in
>>> initialize_positions
>>>     self.density.set_positions(spos_ac, self.wfs.rank_a)
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/density.py", line 104, in
>>> set_positions
>>>     self.ghat.set_positions(spos_ac)
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/lfc.py", line 260, in
>>> set_positions
>>>     movement |= sphere.set_position(spos_c, self.gd, self.cut)
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/lfc.py", line 89, in
>>> set_position
>>>     for beg_c, end_c, sdisp_c in gd.get_boxes(spos_c, rcut, cut):
>>>   File "/usr/lib/python2.7/dist-packages/gpaw/grid_descriptor.py", line
>>> 263, in get_boxes
>>>     (tuple(spos_c) + (beg_c, end_c)))
>>> RuntimeError: Atom at 0.736 0.949 0.750 too close to boundary (beg. of
>>> box [ 88 117   6], end of box [113 142  31])
>>>
>>> I know this has to do with the augmentation sphere being out of
>>> bounds--not the atom itself
>>> mentioned here
>>> https://listserv.fysik.dtu.dk/pipermail/gpaw-users/2010-July/000227.html
>>>
>>> I am only working with carbon nanotubes (carbon and hydrogen atoms) so I
>>> am not using any heavy metals. I can of course avoid the error by imposing
>>> periodic boundary conditions, but it is troubling that no matter how big the
>>> box is (note the size mentioned in the error message) this error still comes
>>> up.
>>>
>>> Does this suggest my basis set is not right (I just used dzp since that
>>> seems to be the standard for most atoms)? What do I have to do to fix this?
>>>
>>> Thank you,
>>> Alex Eftimiades
>>>
>>> _______________________________________________
>>> gpaw-users mailing list
>>> gpaw-users at listserv.fysik.dtu.dk
>>> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users
>>>
>>
>>
>
> _______________________________________________
> gpaw-users mailing list
> gpaw-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.fysik.dtu.dk/pipermail/gpaw-users/attachments/20111018/902ed997/attachment.html