[gpaw-users] Transport calculation--atom "too close to boundary"
Alex Eftimiades
alexeftimiades at gmail.com
Wed Oct 26 21:57:11 CEST 2011
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/20111026/95bd4185/attachment.html
More information about the gpaw-users
mailing list