[gpaw-users] Transport calculation--atom "too close to boundary"
Alex Eftimiades
alexeftimiades at gmail.com
Wed Oct 26 17:44:16 CEST 2011
Ok, this is what I have so far (attached.)
On Tue, Oct 25, 2011 at 10:52 AM, jingzhe Chen <jingzhe.chen at gmail.com>wrote:
> Hi,
>
> Could u send me your script and structure file?
>
> Best.
> Jingzhe
>
>
>
> 2011/10/24 Alex Eftimiades <alexeftimiades at gmail.com>
>
>> Hello all,
>>
>> It would seem making setting the system pbc to (0,0,1) did not make a
>> difference, however I found that the reason it was not working was because
>> the lead atoms were not centered within *pl_cell*
>> I have no idea how to fix this problem. Where is pl_cell usually centered
>> about anyway?
>>
>> Alex
>>
>> On Oct 20, 2011, at 11:49 AM, jingzhe Chen wrote:
>>
>> 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/20111026/0365df5c/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nanotube_transport2.py
Type: text/x-python
Size: 2246 bytes
Desc: not available
Url : http://listserv.fysik.dtu.dk/pipermail/gpaw-users/attachments/20111026/0365df5c/attachment-0002.py
-------------- next part --------------
A non-text attachment was scrubbed...
Name: structure2.py
Type: text/x-python
Size: 12602 bytes
Desc: not available
Url : http://listserv.fysik.dtu.dk/pipermail/gpaw-users/attachments/20111026/0365df5c/attachment-0003.py
More information about the gpaw-users
mailing list