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

[jingzhe Chen]

Hi Alex,

      You are right, leads are periodic while scattering region not.  When u
set pbc as (0,0,1),  lead calculation follow it,
and the scattering region use (0, 0).  (It does not make sense you have left
lead is (0, 0, 1) and right lead is (1, 0 ,1), the
pbc in x, y directions should be consistent for leads and scattering
region).   As for scattering region,the pbc in z
direction has no physical meaning, because 0 means zero boundary, 1 for
periodical, you only have these two options, and each of them is not fit,
but 1 can bypass that error.  Anyway, it may be better to fix it as 1 in the
code.

     Best.
     Jingzhe



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

> That makes more sense, but even so, the system as a whole is not
> periodic--even along the transport direction. Consider this example:
> (forgive the bad ACII drawing)
>
> [Pt]--[Pt]--[Pt]--[H]  [H]--[Na]--[Na]--[Na]
>
> Clearly the left lead is period along the transport direction, and the
> right lead is periodic along the transport direction, but the system as a
> whole is not. That is my only concern in setting the pbc of the system
> periodic along any direction.
>
> Unless the code never applies this condition to the system as a whole and
> only applies the setting to each lead--so if I set system pbc to (0,0,1) I
> am really only setting the left and right lead unit cells' pbc to (0,0,1).
> That would be fine, although it would raise the question of dealing with a
> situation in which one of the leads had a pbc of say (1,0,1) and you wanted
> the other lead to have a pbc of (0,0,1).
>
> Thanks for the quick responses.
> Alex Eftimiades
>
>
> On Tue, Oct 18, 2011 at 1:14 PM, jingzhe Chen <jingzhe.chen at gmail.com>wrote:
>
>> 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/20111020/e450300c/attachment.html