kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/issues2019-02-09T22:04:35Zhttps://gitlab.kwant-project.org/kwant/kwant/issues/259Switch discrete symmetry types to Enum2019-02-09T22:04:35ZAnton AkhmerovSwitch discrete symmetry types to EnumThe following discussion from !257 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/257#note_21139): (+1 comment)
> @jbweston I'm wondering if we should make symmetries also an `Enum` class (probably outside of this MR).The following discussion from !257 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/257#note_21139): (+1 comment)
> @jbweston I'm wondering if we should make symmetries also an `Enum` class (probably outside of this MR).futurehttps://gitlab.kwant-project.org/kwant/kwant/issues/234Improve html representation of discretizer's builders2019-11-28T14:39:32ZAnton AkhmerovImprove html representation of discretizer's buildersHere is what we have now (as of v1.4.0a1):
![image](/uploads/b4f8ed42c49384a463b71d57586befe7/image.png)
Several improvements come to mind:
- It's already an html representation, we could sparingly apply a couple of tags
- We should mention that this is a template builder produced by discretization
- We should hide the internal names and expose the parameters that this builder expects, as well as the number of d.o.f.Here is what we have now (as of v1.4.0a1):
![image](/uploads/b4f8ed42c49384a463b71d57586befe7/image.png)
Several improvements come to mind:
- It's already an html representation, we could sparingly apply a couple of tags
- We should mention that this is a template builder produced by discretization
- We should hide the internal names and expose the parameters that this builder expects, as well as the number of d.o.f.Kwant 1.4.xhttps://gitlab.kwant-project.org/kwant/kwant/issues/216Implement resistance matrix2019-02-09T22:09:32ZAnton AkhmerovImplement resistance matrixVery frequently the users need to compute different multi-terminal resistances ($`σ_{xy}`$ for example).
This requires either performing an inverse (either of a subblock or a pseudoinverse) of the conductance matrix.
Additionally we now offer an easy way to compute the scattering in presence of Andreev reflection, but our conductance matrix does not treat the Andreev reflections properly.Very frequently the users need to compute different multi-terminal resistances ($`σ_{xy}`$ for example).
This requires either performing an inverse (either of a subblock or a pseudoinverse) of the conductance matrix.
Additionally we now offer an easy way to compute the scattering in presence of Andreev reflection, but our conductance matrix does not treat the Andreev reflections properly.futurehttps://gitlab.kwant-project.org/kwant/kwant/issues/136Spectrum: better compute bands2018-09-20T07:55:27ZAnton AkhmerovSpectrum: better compute bandsThere are several things we could consider:
* Allowing to select a sub-range of bands and to use sparse diagonalization (appropriate for large unit cells of a lead or spectra of closed systems).
* Do a better job resolving level crossings once we depend on Debian stretch (see the [blog post](https://quantumtinkerer.tudelft.nl/blog/connecting-the-dots/) outlining the algorithm). This one especially leads to better quality plots.
* Perhaps utilize conservation laws if present (both for computation and representation of the bands).There are several things we could consider:
* Allowing to select a sub-range of bands and to use sparse diagonalization (appropriate for large unit cells of a lead or spectra of closed systems).
* Do a better job resolving level crossings once we depend on Debian stretch (see the [blog post](https://quantumtinkerer.tudelft.nl/blog/connecting-the-dots/) outlining the algorithm). This one especially leads to better quality plots.
* Perhaps utilize conservation laws if present (both for computation and representation of the bands).Kwant 1.5Anton AkhmerovAnton Akhmerovhttps://gitlab.kwant-project.org/kwant/kwant/issues/341Discretizer doesn't work with numpy arrays in locals2019-12-20T10:01:48ZDániel VarjasDiscretizer doesn't work with numpy arrays in localsHere is a minimal example, where discretizer fails with a numpy array in `locals`. This is relevant for more complicated cases, where the matrix coefficient can't be easily expressed in terms of Pauli matrices, like higher spin matrices.
```python
sz = np.diag([1, -1])
subs={'sz': sz}
ham="""
Bz * sz
"""
kwant.continuum.discretize(ham, locals=subs, coords=['x', 'y'])
```
The problem is, it calls `sympy.sympify` on every value in `locals` which returns an `ImmutableDenseNDimArray` which doesn't have the same interface as other `sympy` expressions. A solution is to pass `sympy.Matrix(sz)` instead. This is inconvenient and not clear from the docs or the error message why this error occurs.
The solution is simple, one needs to test for numpy arrays and cast them to sympy matrices separately. I implemented it in this `qsymm` [MR](https://gitlab.kwant-project.org/qt/qsymm/merge_requests/14) which uses a copy of `kwant.continuum.common`, so porting that solution here would be straightforward.Here is a minimal example, where discretizer fails with a numpy array in `locals`. This is relevant for more complicated cases, where the matrix coefficient can't be easily expressed in terms of Pauli matrices, like higher spin matrices.
```python
sz = np.diag([1, -1])
subs={'sz': sz}
ham="""
Bz * sz
"""
kwant.continuum.discretize(ham, locals=subs, coords=['x', 'y'])
```
The problem is, it calls `sympy.sympify` on every value in `locals` which returns an `ImmutableDenseNDimArray` which doesn't have the same interface as other `sympy` expressions. A solution is to pass `sympy.Matrix(sz)` instead. This is inconvenient and not clear from the docs or the error message why this error occurs.
The solution is simple, one needs to test for numpy arrays and cast them to sympy matrices separately. I implemented it in this `qsymm` [MR](https://gitlab.kwant-project.org/qt/qsymm/merge_requests/14) which uses a copy of `kwant.continuum.common`, so porting that solution here would be straightforward.https://gitlab.kwant-project.org/kwant/kwant/issues/340Use sphinx directives in docstrings to denote when a feature was added / depr...2019-11-28T14:19:51ZJoseph WestonUse sphinx directives in docstrings to denote when a feature was added / deprecatedI often find it useful when browsing the documentation to know when a particular feature was added / deprecated.
Sphinx has [directives](https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-versionadded) for marking this.
We would essentially need to look over the "whatsnew" files and annotate the docstrings of the corresponding functionality with `.. versionadded`.I often find it useful when browsing the documentation to know when a particular feature was added / deprecated.
Sphinx has [directives](https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-versionadded) for marking this.
We would essentially need to look over the "whatsnew" files and annotate the docstrings of the corresponding functionality with `.. versionadded`.