[gpaw-users] Transport calculation--atom "too close to boundary"
Alex Eftimiades
alexeftimiades at gmail.com
Sat Oct 29 04:32:09 CEST 2011
Thanks--It seems to be working now. That is interesting--about the
boundary conditions. I do not think I would have realized that, but it
makes sense after you explained it.
So then--just out of curiosity--why does the code center pl_cells in
multi-lead calculations about all axes?
Alex
On Oct 28, 2011, at 4:28 PM, jingzhe Chen wrote:
>
> 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/94175f7e/attachment.html
More information about the gpaw-users
mailing list