Re: [Kwant] issues with Current calculation
Hi Sergey, Can you post a complete script that reproduces your problem? Sergey Slizovskiy wrote: > I get the following suspicious message: The size of the file > /home/sergey/.local/lib/python3.6/site-packages/kwant/operator.cpython-36m-x86_64-linux-gnu.so > is 2734 KB. Do you really want to load it? On my amd64 Linux system the operator*.so files are also of the order of 2-3 MB, so this is not unusual. However, I've never seen the message "Do you really want to load it?" when importing a package. Are you sure that the installation of Kwant went well? You can run all tests using python3 -c 'import kwant; kwant.test(verbose=False)' Since you are on Linux, it could be easier to use binary packages for Kwant that exist for Debian, Ubuntu and Arch. There exist also conda packages, if you like to use that Python distribution. Installing Kwant with pip is like compiling it from source locally. For good performance, you must make sure that Kwant is linked against a decent BLAS + LAPACK and also against MUMPS. Christoph
Re: [Kwant] issues with Current calculation
Hi Christoph, This is a well-working code that computes conductance for graphene with 2 leads (conductance is now commented in the end). The issue appears at line 485. Loading the large package warning may be due to running from Eric6 Python IDE that I use. I have now the latest 1.4 Kwant version installed via pip3 , which added the necessity to remove the default values from "args" parameter list, as it's no longer supported As for ppa install, I might be doing something wrong: (Linux Mint 19 = Ubuntu bionic) sudo add-apt-repository ppa:kwant-project/ppa sudo apt-get update sudo apt-get install kwant returns: "Unable to locate package kwant" The test python3 -c 'import kwant; kwant.test(verbose=False)' returns 21 warnings: (see below) .local/lib/python3.6/site-packages/kwant/tests/test_plotter.py::test_map /home/sergey/.local/lib/python3.6/site-packages/numpy/lib/function_base.py:3652: RuntimeWarning: Invalid value encountered in percentile interpolation=interpolation) /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1300: RuntimeWarning: invalid value encountered in greater overflow_pct = 100 * np.sum(unmasked_data > new_vmax) / len(unmasked_data) /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1301: RuntimeWarning: invalid value encountered in less underflow_pct = 100 * np.sum(unmasked_data < new_vmin) / len(unmasked_data) .local/lib/python3.6/site-packages/kwant/tests/test_plotter.py::test_spectrum /home/sergey/.local/lib/python3.6/site-packages/mpl_toolkits/mplot3d/axes3d.py:1069: UserWarning: Axes3D.figure.canvas is 'None', mouse rotation disabled. Set canvas then call Axes3D.mouse_init(). "Axes3D.figure.canvas is 'None', mouse rotation disabled. " /home/sergey/.local/lib/python3.6/site-packages/numpy/core/fromnumeric.py:83: RuntimeWarning: invalid value encountered in reduce return ufunc.reduce(obj, axis, dtype, out, **passkwargs) .local/lib/python3.6/site-packages/kwant/tests/test_plotter.py::test_density_interpolation /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result. field_out[field_slice] += magns /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result. field_out[field_slice] += magns /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result. field_out[field_slice] += magns /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result. field_out[field_slice] += magns /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result. field_out[field_slice] += magns /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result. field_out[field_slice] += magns .local/lib/python3.6/site-packages/kwant/tests/test_plotter.py::test_current_interpolation /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result. field_out[field_slice] += magns /home/sergey/.local/lib/python3.6/site-packages/kwant/plotter.py:1684: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated
Re: [Kwant] issues with Current calculation
Hi, > I am trying new Kwant 1.3 features on a very simple example of > graphene monolayer, and, apart from a standard well-working code I add: > > for x in sys.sites(): x.family.norbs=1 for x in leadxp.sites(): > x.family.norbs=1 for x in leadxm.sites(): x.family.norbs=1 (to avoid > norbs not defined error) > > ... > > J_0 = kwant.operator.Current(sys) wf = > kwant.solvers.default.wave_function(sys, energy=0.01, > args=[phi,chempot,0]) psi=wf(1) current = J_0(psi) > 'psi' is a bunch of wavefunctions, but the operators only work on one wavefunction at a time, so you'd have to : currents = [J_0(p) for p in psi] to get the current for each wavefunction. This is actually a pretty common thing to want to do, so it would make sense for the operators to be able to work in a "vectorized" manner. I'll open an enhancement issue on the bugtracker. Happy Kwanting, Joe
Re: [Kwant] issues with Current calculation
Thank you, Joseph, It could be nice to have this in tutorials. In my case, I still get a error Exception "unhandled kwant._common.UserCodeError" Error occurred in user-supplied value function "hopping". Although, my hoppings are pretty innocent and conductance calculation works fine On 18/10/18 17:04, Joseph Weston wrote: currents = [J_0(p) for p in psi] Thanks, Sergey
Re: [Kwant] issues with Current calculation
You need to provide the parameters to the current operator when you call it, because it needs to evaluate the Hamiltonian to calculate the current (IIRC this is in the docs). Happy Kwanting, Joe On 10/18/2018 06:16 PM, Sergey Slizovskiy wrote: > Thank you, Joseph, > It could be nice to have this in tutorials. > In my case, I still get a error > Exception "unhandled kwant._common.UserCodeError" > Error occurred in user-supplied value function "hopping". > > Although, my hoppings are pretty innocent and conductance calculation > works fine > > On 18/10/18 17:04, Joseph Weston wrote: >> currents = [J_0(p) for p in psi] > > Thanks, > > Sergey >
Re: [Kwant] issues with Current calculation
Hi Joe, Thank you, now it works! But I am a bit confused about the physical meaning of the current, created by modes in lead n. How to plot the real current between the two leads? Imagine, as the simplest case, that my geometry is inversion-symmetric, so that lead 0 goes into lead 1 under inversion. Then I expect the current to be inversion-symmetric as well. Thanks, Sergey On 18/10/18 17:30, Joseph Weston wrote: You need to provide the parameters to the current operator when you call it, because it needs to evaluate the Hamiltonian to calculate the current (IIRC this is in the docs). Happy Kwanting, Joe On 10/18/2018 06:16 PM, Sergey Slizovskiy wrote: Thank you, Joseph, It could be nice to have this in tutorials. In my case, I still get a error Exception "unhandled kwant._common.UserCodeError" Error occurred in user-supplied value function "hopping". Although, my hoppings are pretty innocent and conductance calculation works fine On 18/10/18 17:04, Joseph Weston wrote: currents = [J_0(p) for p in psi] Thanks, Sergey
Re: [Kwant] Understanding current maps
Hi Crhistoph, Thanks a lot for the detailed information. Now I understand much better how the algorithm works. For me it's good enough as it is now, I just wanted to understand a little bit more how to interpret the maps I get. Kind regards, Marc Marc Vila Tusell La Caixa - Severo Ochoa PhD in the Theoretical and Computational Nanoscience Group Catalan Institute of Nanoscience and Nanotechnology (ICN2) Barcelona Institute of Science and Technology (BIST) Additional information: http://icn2.cat/en/theoretical-and-computational-nanoscience-group https://www.researchgate.net/profile/Marc_Vila_Tusell https://www.becarioslacaixa.net/marc-vila-tusell-BI00042?nav=true https://orcid.org/-0001-9118-421X From: Christoph Groth Sent: Wednesday, October 17, 2018 11:00 AM To: Marc Vila Cc: kwant-discuss@kwant-project.org Subject: Re: [Kwant] Understanding current maps Marc Vila wrote: > I thought the current was plotted with kwant.plotter.current(), so I > just checked that documentation. Now I see that it's a shortcut for > the stremplot. kwant.plotter.current() calls kwant.plotter.streamplot() to do the plotting which in turns piggybacks on matplotlib.streamplot() to trace the streamlines. The added value of kwant.plotter.streamplot() is that it plots both the streamlines (using matplotlib's streamplot()) and the background color plot (using matplotlib's imshow()). > I understand your explanation about how the lines are drawn, but, if > the algorithm doesn't know about the form of the current field, how > does it know how thick it needs to draw the arrow? The current field data is of course available to matplotlib.streamplot(). It's just that the streamline tracing algorithm doesn't use this information (if you normalize the stream speed to 1 everywhere, you'd get the same streamlines). When plotting the streamlines, the density is taken into account. > In any case, could it be safer to plot the arrows with always the same > thickness and just look at the colorplot to see the value? We tried that, but then in a case like yours the whole plot is full of streamlines even where the current density is practically zero. This is ugly and confusing. One can also imagine a completely different kind of streamplot where all streamlines have the same thickness and it's their density that is proportional to the local flow speed. Such a streamplot would avoid the many problems and would correspond better to what physicists are used to. But it would require implementing something completely independent from matplotlib.streamplot(). Meanwhile, matplotlib.streamplot() works as follows: The plotting domain is subdivided into a grid of cells (30*30 by default) where each cell can have, at most, one traversing streamline. The streamlines start at points specified by the 'start_points' parameter. The docstring doesn't say what happens if 'start_points' is not given, but looking at the source code unearths the following: def _gen_starting_points(shape): """Yield starting points for streamlines. Trying points on the boundary first gives higher quality streamlines. This algorithm starts with a point on the mask corner and spirals inward. This algorithm is inefficient, but fast compared to rest of streamplot. """ I suspect that a better algorithm to generate starting points would have to actually look at the stream field and try to put streamlines at significant places, like the centers of "streams". But such an algorithm would be tricky, because it would also have to respect that streamlines should be equally spaced. In any way, plotter.streamplot() is just a small part of Kwant, so we don't want to spend too much time on it. (We've already spent a lot of time on doing the current density interpolation right.) If there are people who are motivated to improve current density plots, I'd be happy to assist.
Re: [Kwant] Understanding current maps
Hi Anton, Thanks for the quick answer. Your and Christoph answer have been useful?. Thanks again! Bests, Marc Marc Vila Tusell La Caixa - Severo Ochoa PhD in the Theoretical and Computational Nanoscience Group Catalan Institute of Nanoscience and Nanotechnology (ICN2) Barcelona Institute of Science and Technology (BIST) Additional information: http://icn2.cat/en/theoretical-and-computational-nanoscience-group https://www.researchgate.net/profile/Marc_Vila_Tusell https://www.becarioslacaixa.net/marc-vila-tusell-BI00042?nav=true https://orcid.org/-0001-9118-421X From: Anton Akhmerov Sent: Tuesday, October 16, 2018 1:29 PM To: Marc Vila Cc: kwant-discuss@kwant-project.org Subject: Re: [Kwant] Understanding current maps Hi Marc, Observe that the arrows at the bottom edge are positioned away from the maximum. Therefore it's likely that there the current density is lower than at the maximum of the top edge. Best, Anton On Tue, Oct 16, 2018 at 12:56 PM Marc Vila mailto:marc.v...@icn2.cat>> wrote: Dear Kwant developers, I'm playing with the current maps and there is something I don't understand. I attatch a current plot of a 2 terminal-device of some edge states in a particular model of graphene (the current is the sum of all wavefunctions from the incoming lead which is positioned at the left). I understand thus that the arrows point from left to right, it's the current direction. But then, in one edge I have a stronger color meaning there is more current there, but on the other hand, in the other edge the arrow is thicker, which I assume it also represents more current. Does the arrow thickness and color represent the same thing and therefore both edges have the same current or do they represent different things and so I'm missing something? Could you please clarify this for me? In addition, when I plot the spin current projected on the Z axis (as in Kwant's documentation), I assume that the direction of the arrow is for example where the spin-up electrons move, while the spin-down electrons move to the other direction. Is this correct? Thank you in advance for your help. Bests?, Marc Marc Vila Tusell La Caixa - Severo Ochoa PhD in the Theoretical and Computational Nanoscience Group Catalan Institute of Nanoscience and Nanotechnology (ICN2) Barcelona Institute of Science and Technology (BIST) Additional information: http://icn2.cat/en/theoretical-and-computational-nanoscience-group https://www.researchgate.net/profile/Marc_Vila_Tusell https://www.becarioslacaixa.net/marc-vila-tusell-BI00042?nav=true https://orcid.org/-0001-9118-421X
