[gpaw-users] Transport calculation--atom "too close to boundary"
jingzhe Chen
jingzhe.chen at gmail.com
Thu Oct 27 16:54:15 CEST 2011
Hi,
I can not run your script for lack of Avogadro module, if I comment
the related lines, can not repeat your error.
Can you send me a script similar to the example in the wiki page, i.e., you
just give a scattering region structure, then
define pl_atoms, pl_cells?
Best.
Jingzhe
2011/10/26 Alex Eftimiades <alexeftimiades at gmail.com>
> I should note that the transport file I sent should work correctly because
> the system pbc is set to (1,1,1). I did this to obtain some results (I have
> very large unit cells.) I would still prefer zero boundary conditions, so
> just change:
> pbc(1,1,1)
> to
> pbc(0,0,1)
> and you should encounter the problems I have been facing.
>
> On Oct 26, 2011, at 11:44 AM, Alex Eftimiades wrote:
>
> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> <nanotube_transport2.py><structure2.py>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.fysik.dtu.dk/pipermail/gpaw-users/attachments/20111027/8e2a4070/attachment.html
More information about the gpaw-users
mailing list