kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/issues2019-02-09T22:08:07Zhttps://gitlab.kwant-project.org/kwant/kwant/issues/224Provide useful error message when `Builder.fill` starts with a site that does...2019-02-09T22:08:07ZChristoph GrothProvide useful error message when `Builder.fill` starts with a site that doesn't belong to the templateThe current error message is particularly confusing, because the above situation triggers an exception that is caught by a try block that is not prepared to handle it, and so the error visible to the user is in the except block...The current error message is particularly confusing, because the above situation triggers an exception that is caught by a try block that is not prepared to handle it, and so the error visible to the user is in the except block...Kwant 1.4https://gitlab.kwant-project.org/kwant/kwant/issues/126latex documentation no longer builds2017-09-13T14:05:02ZChristoph Grothlatex documentation no longer buildsKwant 1.3.2https://gitlab.kwant-project.org/kwant/kwant/issues/393D plotter failure with nontrivial sizes2017-12-13T15:07:38ZAnton Akhmerov3D plotter failure with nontrivial sizesTo reproduce use matplotlib>=1.5.0 and try to plot a 3D system with site_size set to something. Verify that in the resulting figure `fig.axes[0].collections[0].transforms` have a shape `(N,)`, and not `(N, 3, 3)`, as would be expected by matplotlib. This results in a failure to plot inside a notebook with an inline backend.
Looking at the source code, I see that transforms get reshaped [over here](https://gitlab.kwant-project.org/kwant/kwant/blob/master/kwant/plotter.py#L298); my guess that's where the problem originates from.
In an interactive backend setting the sizes doesn't seem to have any effect at all (which may or may not be a separate bug).To reproduce use matplotlib>=1.5.0 and try to plot a 3D system with site_size set to something. Verify that in the resulting figure `fig.axes[0].collections[0].transforms` have a shape `(N,)`, and not `(N, 3, 3)`, as would be expected by matplotlib. This results in a failure to plot inside a notebook with an inline backend.
Looking at the source code, I see that transforms get reshaped [over here](https://gitlab.kwant-project.org/kwant/kwant/blob/master/kwant/plotter.py#L298); my guess that's where the problem originates from.
In an interactive backend setting the sizes doesn't seem to have any effect at all (which may or may not be a separate bug).Kwant 1.3.2Joseph WestonJoseph Westonhttps://gitlab.kwant-project.org/kwant/kwant/issues/31Broken plotting of sites on mpl v=1.42017-06-21T16:26:20ZAnton AkhmerovBroken plotting of sites on mpl v=1.4Some plot types are failing on matplotlib 1.4.x and 1.5.0. To reproduce, run tutorial 5 (plotting), and compare the output with http://kwant-project.org/doc/1/tutorial/tutorial6Some plot types are failing on matplotlib 1.4.x and 1.5.0. To reproduce, run tutorial 5 (plotting), and compare the output with http://kwant-project.org/doc/1/tutorial/tutorial6https://gitlab.kwant-project.org/kwant/kwant/issues/297fix kaniko2019-05-27T11:51:33ZAnton Akhmerovfix kanikoKaniko builds are failing; the fix might well be similar to what we applied some time ago in our [docker image](https://gitlab.kwant-project.org/qt/research-docker).
Once the builds work again, we should move the installation of sphinx extensions out of CI, see !296.Kaniko builds are failing; the fix might well be similar to what we applied some time ago in our [docker image](https://gitlab.kwant-project.org/qt/research-docker).
Once the builds work again, we should move the installation of sphinx extensions out of CI, see !296.https://gitlab.kwant-project.org/kwant/kwant/issues/282Use collections.abc2019-02-28T10:40:01ZAnton AkhmerovUse collections.abcImporting abstract base classes like `Iterable` should be done from `collections.abc` instead of directly from collections, and it will be disabled in Python 3.8; see the [docs](https://docs.python.org/3/library/collections.abc.html#module-collections.abc).Importing abstract base classes like `Iterable` should be done from `collections.abc` instead of directly from collections, and it will be disabled in Python 3.8; see the [docs](https://docs.python.org/3/library/collections.abc.html#module-collections.abc).https://gitlab.kwant-project.org/kwant/kwant/issues/238"kwant.operator._normalize_site/hopping_where" yields an errror if sites in ...2019-10-23T11:40:01ZPhillipp Reck"kwant.operator._normalize_site/hopping_where" yields an errror if sites in hoppings of "where" are already of type int (i.e. of the finalized system)Dear kwant developers,
playing around with the kwant.operator module, I came across an error(/bug?) which appeared when giving a "where" with the sites being already of type "int" instead of an instance of kwant.builder.Site. Christoph asked me to create this issue here.
The reason for the error is in the "kwant.operator._normalize_sites_where" and "kwant.operator._normalize_hoppings_where" methods. As far as I see, these two methods are used to make "where" uniform (i.e. if it is None: list of all hoppings, if it is a callable: only matching hoppings, else: convert from sites of the unfinalized system (kwant.builder.Site) to sites of the finalized system (int).
The problem arises in the else-statement:
else:
try:
_where = list(syst.id_by_site[s] for s in where)
except AttributeError:
_where = list(where)
If 's' is already an integer, then it is not an available key in the dictionary syst.id_by_site. Although it is checked for an AttributeError, I think that an exception for a KeyError would be needed here (and in kwant.operator._normalize_hoppings_where).
Thank you very much for your work.
Best regards,
Phillipp ReckDear kwant developers,
playing around with the kwant.operator module, I came across an error(/bug?) which appeared when giving a "where" with the sites being already of type "int" instead of an instance of kwant.builder.Site. Christoph asked me to create this issue here.
The reason for the error is in the "kwant.operator._normalize_sites_where" and "kwant.operator._normalize_hoppings_where" methods. As far as I see, these two methods are used to make "where" uniform (i.e. if it is None: list of all hoppings, if it is a callable: only matching hoppings, else: convert from sites of the unfinalized system (kwant.builder.Site) to sites of the finalized system (int).
The problem arises in the else-statement:
else:
try:
_where = list(syst.id_by_site[s] for s in where)
except AttributeError:
_where = list(where)
If 's' is already an integer, then it is not an available key in the dictionary syst.id_by_site. Although it is checked for an AttributeError, I think that an exception for a KeyError would be needed here (and in kwant.operator._normalize_hoppings_where).
Thank you very much for your work.
Best regards,
Phillipp Reckhttps://gitlab.kwant-project.org/kwant/kwant/issues/180kwant.continuum.sympify fails to raise a warning in some cases2017-12-13T15:07:38ZJoseph Westonkwant.continuum.sympify fails to raise a warning in some casesto reproduce:
```
import kwant
def discretized_hamiltonian(a):
hamiltonian = ("(0.5 * hbar**2 * (k_x**2 + k_y**2 + k_z**2) / m_eff - mu + V(x)) * sigma_0 + "
"alpha * (k_y * sigma_x - k_x * sigma_y) + "
"0.5 * g * mu_B * (B_x * sigma_x + B_y * sigma_y + B_z * sigma_z)")
hamiltonian = kwant.continuum.sympify(hamiltonian)
def do(subs):
tb_ham, coords = kwant.continuum.discretize_symbolic(hamiltonian)
templ = kwant.continuum.build_discretized(
tb_ham, grid_spacing=a, coords=coords, locals=subs)
return templ
templ = do({'g': 0, 'alpha': 0})
return templ
discretized_hamiltonian(10)
```to reproduce:
```
import kwant
def discretized_hamiltonian(a):
hamiltonian = ("(0.5 * hbar**2 * (k_x**2 + k_y**2 + k_z**2) / m_eff - mu + V(x)) * sigma_0 + "
"alpha * (k_y * sigma_x - k_x * sigma_y) + "
"0.5 * g * mu_B * (B_x * sigma_x + B_y * sigma_y + B_z * sigma_z)")
hamiltonian = kwant.continuum.sympify(hamiltonian)
def do(subs):
tb_ham, coords = kwant.continuum.discretize_symbolic(hamiltonian)
templ = kwant.continuum.build_discretized(
tb_ham, grid_spacing=a, coords=coords, locals=subs)
return templ
templ = do({'g': 0, 'alpha': 0})
return templ
discretized_hamiltonian(10)
```Kwant 1.3.2Joseph WestonJoseph Westonhttps://gitlab.kwant-project.org/kwant/kwant/issues/170tests fail under Cython 0.26.12017-09-13T14:05:02ZJoseph Westontests fail under Cython 0.26.1Every time we try to pickle something we get:
```
E TypeError: self.edge_ids,self.edge_ids_by_edge_nr,self.heads,self.heads_idxs,self.tails,self.tails_idxs cannot be converted to a Python object for pickling
```
This error does not appear for Cython 0.25.2Every time we try to pickle something we get:
```
E TypeError: self.edge_ids,self.edge_ids_by_edge_nr,self.heads,self.heads_idxs,self.tails,self.tails_idxs cannot be converted to a Python object for pickling
```
This error does not appear for Cython 0.25.2https://gitlab.kwant-project.org/kwant/kwant/issues/162correct physics.leads.modes docstring2017-08-30T07:25:38ZJoseph Westoncorrect physics.leads.modes docstringIn the `Notes` section we mention the sort ordering of the propagating modes, which is incorrect.
We should refer to the documentation of `PropagatingModes` for the sort ordering, but keep the comment about the propagating modes being normalized to unit current.In the `Notes` section we mention the sort ordering of the propagating modes, which is incorrect.
We should refer to the documentation of `PropagatingModes` for the sort ordering, but keep the comment about the propagating modes being normalized to unit current.Kwant 1.3.2https://gitlab.kwant-project.org/kwant/kwant/issues/156small correction in the documentation2017-08-29T09:26:05ZAbbout Adelsmall correction in the documentationIn the section "Computing local quantities: densities and currents", the function field_direction(pos,r0,delta) is defined with the condition:
if r==0: m_i=[0,0,1]
This should be m_i =[0,0,-1]
This explains why we get some strange pattern in the present figures on the online documentation. With this minor correction, the result will be better and the topological hall effect clearly visible.In the section "Computing local quantities: densities and currents", the function field_direction(pos,r0,delta) is defined with the condition:
if r==0: m_i=[0,0,1]
This should be m_i =[0,0,-1]
This explains why we get some strange pattern in the present figures on the online documentation. With this minor correction, the result will be better and the topological hall effect clearly visible.Kwant 1.3.2Joseph WestonJoseph Westonhttps://gitlab.kwant-project.org/kwant/kwant/issues/145Broken plotting of sites2017-12-05T14:42:27ZJoseph WestonBroken plotting of sitesSome plot types are failing (have not yet tested across MPL versions).
Seems to be related to passing/not passing parameters for sites (e.g. colour).
To reproduce, run tutorial 5 (plotting), and compare the output with http://kwant-project.org/doc/1/tutorial/tutorial6Some plot types are failing (have not yet tested across MPL versions).
Seems to be related to passing/not passing parameters for sites (e.g. colour).
To reproduce, run tutorial 5 (plotting), and compare the output with http://kwant-project.org/doc/1/tutorial/tutorial6Kwant 1.3.2https://gitlab.kwant-project.org/kwant/kwant/issues/99commutative momentum operators are ignored by discretizer2017-04-03T23:12:39ZRafal Skolasinskicommutative momentum operators are ignored by discretizerIf ``hamiltonian`` is provided in form of ``sympy`` expression and momentum operator is defined as commutative it is ignored.
Compare
```
H = sympy.Symbol('k_x', commutative=False)**2
kwant.continuum.discretize(H, discrete_coordinates='xy', verbose=True)
```
with
```
H = sympy.Symbol('k_x', commutative=True)**2
kwant.continuum.discretize(H, discrete_coordinates='xy', verbose=True)
```If ``hamiltonian`` is provided in form of ``sympy`` expression and momentum operator is defined as commutative it is ignored.
Compare
```
H = sympy.Symbol('k_x', commutative=False)**2
kwant.continuum.discretize(H, discrete_coordinates='xy', verbose=True)
```
with
```
H = sympy.Symbol('k_x', commutative=True)**2
kwant.continuum.discretize(H, discrete_coordinates='xy', verbose=True)
```Rafal SkolasinskiRafal Skolasinskihttps://gitlab.kwant-project.org/kwant/kwant/issues/97improve usage of ``substitutions`` in ``continuum``2017-05-11T22:06:50ZRafal Skolasinskiimprove usage of ``substitutions`` in ``continuum``note: description edited to include larger scope
### type of substitutions:
So far ``substitutions`` accept dictionary in form ``key: sympy expression``. One could also expect it to accept ``strings``, i.e
following works:
```python
>>> kwant.continuum.sympify('k_x**2 + V', substitutions=dict(V=kwant.continuum.sympify('V_0 + V')))
V + V_0 + k_x**2
```
once following fails
```python
>>> kwant.continuum.sympify('k_x**2 + V', substitutions=dict(V='V_0 + V'))
[traceback skipped]
TypeError: unsupported operand type(s) for +: 'Symbol' and 'str'
```
Also currently subsitutions that contains momentum or position operators are ignored, i.e
```python
>>> kwant.continuum.sympify('k_x**2 + k_y**2', substitutions=dict(k_y=0))
k_x**2 + k_y**2
```
### applying substitutions also when input is sympy object:
Currently ``substitutions`` are used only when input type is a string. This was overlooked because initially they were playing role of ``locals`` passed to ``sympy.sympify`` when input was string. It makes sense though to apply them according to their name on already sympified input. For example following to piece of code should do the same:
```python
hamiltonian = 'k_x**2 + V'
substitutions = {'V': kwant.continuum.sympify('V + V_0')}
h = kwant.continuum.lambdify(hamiltonian, substitutions=substitutions)
```
```python
hamiltonian = kwant.continuum.sympify('k_x**2 + V')
substitutions = {'V': kwant.continuum.sympify('V + V_0')}
h = kwant.continuum.lambdify(hamiltonian, substitutions=substitutions)
```
this should address every public function that uses ``substitutions``.note: description edited to include larger scope
### type of substitutions:
So far ``substitutions`` accept dictionary in form ``key: sympy expression``. One could also expect it to accept ``strings``, i.e
following works:
```python
>>> kwant.continuum.sympify('k_x**2 + V', substitutions=dict(V=kwant.continuum.sympify('V_0 + V')))
V + V_0 + k_x**2
```
once following fails
```python
>>> kwant.continuum.sympify('k_x**2 + V', substitutions=dict(V='V_0 + V'))
[traceback skipped]
TypeError: unsupported operand type(s) for +: 'Symbol' and 'str'
```
Also currently subsitutions that contains momentum or position operators are ignored, i.e
```python
>>> kwant.continuum.sympify('k_x**2 + k_y**2', substitutions=dict(k_y=0))
k_x**2 + k_y**2
```
### applying substitutions also when input is sympy object:
Currently ``substitutions`` are used only when input type is a string. This was overlooked because initially they were playing role of ``locals`` passed to ``sympy.sympify`` when input was string. It makes sense though to apply them according to their name on already sympified input. For example following to piece of code should do the same:
```python
hamiltonian = 'k_x**2 + V'
substitutions = {'V': kwant.continuum.sympify('V + V_0')}
h = kwant.continuum.lambdify(hamiltonian, substitutions=substitutions)
```
```python
hamiltonian = kwant.continuum.sympify('k_x**2 + V')
substitutions = {'V': kwant.continuum.sympify('V + V_0')}
h = kwant.continuum.lambdify(hamiltonian, substitutions=substitutions)
```
this should address every public function that uses ``substitutions``.Rafal SkolasinskiRafal Skolasinskihttps://gitlab.kwant-project.org/kwant/kwant/issues/92Failure of attach_lead on master2017-04-03T23:12:40ZAnton AkhmerovFailure of attach_lead on masterTo reproduce:
```python
lat = kwant.lattice.honeycomb()
syst = kwant.Builder()
syst[lat.sublattices[0](0, 1)] = syst[lat.sublattices[1](0, 0)] = 0
lead = kwant.Builder(kwant.TranslationalSymmetry(lat.vec([-1, 2])))
lead[lat.sublattices[0](0, 0)] = lead[lat.sublattices[1](0, 0)] = 0
lead[lat.sublattices[0](0, 1)] = lead[lat.sublattices[1](0, 1)] = 0
lead[lat.neighbors()] = 0
kwant.plot(syst)
kwant.plot(lead)
syst.attach_lead(lead)
```To reproduce:
```python
lat = kwant.lattice.honeycomb()
syst = kwant.Builder()
syst[lat.sublattices[0](0, 1)] = syst[lat.sublattices[1](0, 0)] = 0
lead = kwant.Builder(kwant.TranslationalSymmetry(lat.vec([-1, 2])))
lead[lat.sublattices[0](0, 0)] = lead[lat.sublattices[1](0, 0)] = 0
lead[lat.sublattices[0](0, 1)] = lead[lat.sublattices[1](0, 1)] = 0
lead[lat.neighbors()] = 0
kwant.plot(syst)
kwant.plot(lead)
syst.attach_lead(lead)
```Kwant 1.3Anton AkhmerovAnton Akhmerovhttps://gitlab.kwant-project.org/kwant/kwant/issues/75partially broken sphinx builds2017-04-03T23:12:40ZAnton Akhmerovpartially broken sphinx buildsSee the image:
![image](/uploads/c69d4a813314ee08dfb071c84008ceaf/image.png)
See the image:
![image](/uploads/c69d4a813314ee08dfb071c84008ceaf/image.png)
Kwant 1.3Joseph WestonJoseph Westonhttps://gitlab.kwant-project.org/kwant/kwant/issues/66Test failure with matplotlib 1.5.32017-04-03T23:12:40ZAnton AkhmerovTest failure with matplotlib 1.5.3See e.g. https://gitlab.kwant-project.org/jbweston/kwant/builds/2827See e.g. https://gitlab.kwant-project.org/jbweston/kwant/builds/2827https://gitlab.kwant-project.org/kwant/kwant/issues/50Modes: resolving crossings with high velocity2017-04-03T23:12:40ZAnton AkhmerovModes: resolving crossings with high velocityRight now crossing resolution in modes accounts for numerical precision in an inconsistent manner, which may result in false identification of propagating modes as evanescent or vice versa. This is in particular important when the user works in physical units, and absolute values of matrix elements are large.
Example reproducing the bug (in a notebook, comment out the first line for running from a script):
```python
%matplotlib inline
from matplotlib import pyplot
import kwant
import tinyarray as ta
W = 10
mu = 1
scale = 100000
sz = ta.array([[1, 0], [0, -1]])
syst = kwant.Builder(kwant.TranslationalSymmetry((1, 0)))
lat = kwant.lattice.square()
syst[(lat(0, j) for j in range(10))] = scale * mu * sz
syst[lat.neighbors()] = scale * sz
syst = syst.finalized()
kwant.plotter.bands(syst, momenta=401)
len(syst.modes()[0].momenta) # prints "0"
```
The system here is designed to have a lot of crossings at zero energy. Check that setting `scale = 1` results in `modes` finding 28 propagating modes, while scale shouldn't change the number of propagating modes.
@michaelwimmer any ideas for workaround? Rescale `h` and `t` inside the modes function?
PS credit for discovering goes to @basnijholtRight now crossing resolution in modes accounts for numerical precision in an inconsistent manner, which may result in false identification of propagating modes as evanescent or vice versa. This is in particular important when the user works in physical units, and absolute values of matrix elements are large.
Example reproducing the bug (in a notebook, comment out the first line for running from a script):
```python
%matplotlib inline
from matplotlib import pyplot
import kwant
import tinyarray as ta
W = 10
mu = 1
scale = 100000
sz = ta.array([[1, 0], [0, -1]])
syst = kwant.Builder(kwant.TranslationalSymmetry((1, 0)))
lat = kwant.lattice.square()
syst[(lat(0, j) for j in range(10))] = scale * mu * sz
syst[lat.neighbors()] = scale * sz
syst = syst.finalized()
kwant.plotter.bands(syst, momenta=401)
len(syst.modes()[0].momenta) # prints "0"
```
The system here is designed to have a lot of crossings at zero energy. Check that setting `scale = 1` results in `modes` finding 28 propagating modes, while scale shouldn't change the number of propagating modes.
@michaelwimmer any ideas for workaround? Rescale `h` and `t` inside the modes function?
PS credit for discovering goes to @basnijholthttps://gitlab.kwant-project.org/kwant/kwant/issues/86test_PHS_TRIM_degenerate_ordering fails at current master2017-02-01T18:48:14ZBas Nijholttest_PHS_TRIM_degenerate_ordering fails at current masterI decided to run the kwant tests after building the conda package and discovered that a test fails, @pablopiskunow also noticed this.
Reproduce with:
```bash
docker run -it condaforge/linux-anvil bash
yum install -y devtoolset-2-gcc-gfortran
git clone https://gitlab.kwant-project.org/kwant/conda-recipes.git
conda config --add channels kwant
conda build --python 3.5 conda-recipes/kwant-dev
```
Master is now at cdc57cf108e56483d4f1a7129079d5217289fb3eI decided to run the kwant tests after building the conda package and discovered that a test fails, @pablopiskunow also noticed this.
Reproduce with:
```bash
docker run -it condaforge/linux-anvil bash
yum install -y devtoolset-2-gcc-gfortran
git clone https://gitlab.kwant-project.org/kwant/conda-recipes.git
conda config --add channels kwant
conda build --python 3.5 conda-recipes/kwant-dev
```
Master is now at cdc57cf108e56483d4f1a7129079d5217289fb3ehttps://gitlab.kwant-project.org/kwant/kwant/issues/83Plotter tests fail if qt is not installed2017-12-13T15:07:38ZAnton AkhmerovPlotter tests fail if qt is not installedKwant 1.3.2Joseph WestonJoseph Weston