[gpaw-users] Transport calculation--atom "too close to boundary"
jingzhe Chen
jingzhe.chen at gmail.com
Fri Oct 28 22:28:50 CEST 2011
In your script the pl_cell1(pl_cell2) has difference length compared with
junction's cell in x, y direction.
They should be the same, I already put this into the wiki. The reason why
lead can not center in x, y
directions because after centering its potential at the boundary does not
match the scattering region's(missing
a displacement), and the exact match is needed for solving the Poisson
equation with fixed boundary condition.
Best.
Jingzhe
2011/10/28 Alex Eftimiades <alexeftimiades at gmail.com>
> The attached patch fixes the problem. It simply centers the pl atoms about
> all axises rather than just axis 2. It should be applied to
> gpaw/transport/calculator.py
>
> I do not know why it was set to only center about the transport direction
> (except when there are more than two leads), and I might have missed a
> drawback in changing it. However, this does fix the problem of the pl_atoms
> not being centered in their respective pl_cells.
>
> I used the svn version of calculator.py when applying this patch.
>
> Alex
>
>
>
> On Thu, Oct 27, 2011 at 3:07 PM, Alex Eftimiades <alexeftimiades at gmail.com
> > wrote:
>
>> Sorry, it appears the last "calculate trasmission" line is commented out.
>> Use the new attached document--I just tested it (and got the error) before I
>> sent this message off.
>>
>> Alex
>>
>>
>> On Wed, Oct 26, 2011 at 3:57 PM, Alex Eftimiades <
>> alexeftimiades at gmail.com> wrote:
>>
>>> 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/20111028/65f201ff/attachment.html
More information about the gpaw-users
mailing list