kwant issueshttps://gitlab.kwant-project.org/groups/kwant/-/issues2024-01-23T15:03:41Zhttps://gitlab.kwant-project.org/kwant/python-mumps/-/issues/22Use mumps pkgconfig when it becomes available2024-01-23T15:03:41ZAnton AkhmerovUse mumps pkgconfig when it becomes availablehttps://gitlab.kwant-project.org/kwant/python-mumps/-/issues/21Explore releasing gil2024-03-19T20:37:14ZAnton AkhmerovExplore releasing gilAs far as I understand, all the mumps calls should release GIL.As far as I understand, all the mumps calls should release GIL.https://gitlab.kwant-project.org/kwant/kwant/-/issues/428wraparound: cryptic error message when k_x, k_y, ... not provided2023-06-30T16:27:24ZChristoph Grothwraparound: cryptic error message when k_x, k_y, ... not providedEvaluating the Hamiltonian of a wrapped-around system without providing the required momenta parameters leads to an error message that is inscrutable even for advanced users of Kwant. For example, executing the following piece of code (...Evaluating the Hamiltonian of a wrapped-around system without providing the required momenta parameters leads to an error message that is inscrutable even for advanced users of Kwant. For example, executing the following piece of code (only the last line differs from https://kwant-project.org/doc/1/pre/whatsnew/1.3#finalizing-builders-with-multiple-translational-symmetries)
```python
from matplotlib import pyplot
import kwant
lat = kwant.lattice.honeycomb()
sym = kwant.TranslationalSymmetry(lat.vec((1, 0)), lat.vec((0, 1)))
bulk = kwant.Builder(sym)
bulk[ [lat.a(0, 0), lat.b(0, 0)] ] = 0
bulk[lat.neighbors()] = 1
wrapped = kwant.wraparound.wraparound(bulk).finalized()
ham = wrapped.hamiltonian_submatrix()
```
The above code can be fixed by changing the last line to
```python
ham = wrapped.hamiltonian_submatrix(params=dict(k_x=0, k_y=0))
```
but the problem is the unhelpful error message produced by the original snippet:
```
/home/cwg/wo/11/kwant-src/kwant/lattice.py:120: KwantDeprecationWarning: Not specfying norbs is deprecated. Always specify norbs when creating site families.
self.sublattices = [Monatomic(prim_vecs, offset, sname, norb)
Traceback (most recent call last):
File "/home/cwg/wo/11/kwant-src/kwant/builder.py", line 1815, in hamiltonian
value = value(site_i, site_j, *args)
File "/home/cwg/wo/11/kwant-src/kwant/wraparound.py", line 135, in f
acc = acc + val(*out_args)
File "/home/cwg/wo/11/kwant-src/kwant/wraparound.py", line 115, in f
phase = cmath.exp(1j * ta.dot(elem, args[mnp:]))
TypeError: Expecting a number.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/cwg/wo/11/kwant-src/test2.py", line 11, in <module>
ham = wrapped.hamiltonian_submatrix()
File "/home/cwg/wo/11/kwant-src/kwant/_common.py", line 73, in inner
return f(*args, **kwargs)
File "kwant/_system.pyx", line 324, in kwant._system.hamiltonian_submatrix
mat = func(ham, args, params, self.graph, diag, to_norb, to_off,
File "kwant/_system.pyx", line 223, in kwant._system.make_dense_full
h = mat = matrix(ham(ts, fs, *args, params=params), complex)
File "/home/cwg/wo/11/kwant-src/kwant/builder.py", line 1823, in hamiltonian
_raise_user_error(exc, value)
File "/home/cwg/wo/11/kwant-src/kwant/builder.py", line 1719, in _raise_user_error
raise UserCodeError(msg.format(func.__name__)) from exc
kwant._common.UserCodeError: Error occurred in user-supplied value function "f".
See the upper part of the above backtrace for more information.
```https://gitlab.kwant-project.org/kwant/kwant/-/issues/424Wrong example in `kwant.kpm.conductivity` docstring2023-04-19T21:01:55ZDániel VarjasWrong example in `kwant.kpm.conductivity` docstringThe example given in the docstring of `kwant.kpm.conductivity` gives nonsense result. Should use the example in the [tutorial](https://kwant-project.org/doc/dev/tutorial/kpm) instead. The tutorial example uses KPM vectors deep in the bul...The example given in the docstring of `kwant.kpm.conductivity` gives nonsense result. Should use the example in the [tutorial](https://kwant-project.org/doc/dev/tutorial/kpm) instead. The tutorial example uses KPM vectors deep in the bulk, while the docstring example uses random vectors everywhere, giving a poorly averaged result with the default 10 random vectors.https://gitlab.kwant-project.org/kwant/tinyarray/-/issues/24Switch to multi-phase init2023-03-02T09:55:09ZChristoph GrothSwitch to multi-phase initThis will enable compatibility with the new [multiple interpreters](https://peps.python.org/pep-0684/#restricting-extension-modules) feature of Python 3.12.This will enable compatibility with the new [multiple interpreters](https://peps.python.org/pep-0684/#restricting-extension-modules) feature of Python 3.12.https://gitlab.kwant-project.org/kwant/tinyarray/-/issues/23Mutable tinyarrays?2023-03-19T22:51:00ZChristoph GrothMutable tinyarrays?Tinyarrays are currently immutable. This is necessary so that they can be used as dictionary keys, which is the original application of tinyarray (with [Kwant](https://gitlab.kwant-project.org/kwant/kwant)). This issue discusses whethe...Tinyarrays are currently immutable. This is necessary so that they can be used as dictionary keys, which is the original application of tinyarray (with [Kwant](https://gitlab.kwant-project.org/kwant/kwant)). This issue discusses whether and how the tinyarray module could be extended to support mutable arrays as well. It is motivated by requests from tinyarray users.
## Purpose
- With today’s tinyarray it is possible to write code like
```
a /= sqrt(dot(a, a))
b += a
```
The above results in the allocation of two new tinyarray objects. With mutable tinyarrays, both allocations could be avoided.
- Individual elements of an array could be overwritten, allowing to modify elements of a matrix or looping over a vector:
```
v = zeros(2, int)
for v[0] in range(10):
for v[1] in range(10):
...
```
- What else?
## Types
Like tuples and strings, tinyarrays are immutable by design. [Immutability is a prerequisite to hashability](https://docs.python.org/3/faq/design.html#why-must-dictionary-keys-be-immutable), which in turn is necessary for tinyarrays to be usable as dictionary keys. Otherwise, there is technically nothing that prevents tinyarrays from being mutated. After all the underlying memory is writeable.
For some applications mutable tinyarrays would be useful. I can see two ways of achieving that without breaking current applications and backwards compatibility:
- Introduce new tinyarray types that correspond to today’s `ndarray_int`, `ndarray_float`, `ndarray_complex`, only that they are mutable and not hashable. That could be probably done without much code duplication by adding a second template parameter to the `Array` class. That parameter would specify whether the underlying arrays are mutable or not.
- Extend the current types by introducing a flag that determines for each tinyarray instance whether it is mutable or not. Technically, C-API equivalents of magic methods like `__hash__` and `__setitem__` would always be defined, but item assignment would only work for mutable, and hashing only for immutable variants.
The advantage of the first solution is that it would not require accommodating an additional flag in the tinyarray object. Unless we find some trick, an additional boolean flag would increase the object size by 8 bytes (on 64 bit platforms) due to alignment. See the section “data layout” below.
One advantage of the second solution is that the implementation will be most likely simpler. Another advantage would be that while it should not be possible to turn an existing immutable tinyarray object into a mutable one, the other way (=freezing) would be possible and potentially useful.
## API
Independently of the implementation, the API could mostly stay the way it is. One would have to come up with a way of constructing mutable arrays. I see the following possibilites:
- Add an option to `tinyarray.array`, `tinyarray.zeros`, etc. Since for performance reasons tinyarray constructors only accept positional arguments, adding such a “mutable” option would mean it has to go behind the existing “dtype” argument. Thus specifying “mutable” would require specifying “dtype” as well. More importantly, a positional argument for mutability would be incompatible with NumPy.
- Prefix the mutable constructors, e.g. `tinyarray.marray`, etc. Because of backwards compatibility, immutable would have to remain the default (=without prefix).
- Put the mutable constructors into a separate namespace, e.g `tinyarray.mut.array`. This seems attractive, especially if the submodule could have the same contents. Then a user interested in mutable arrays could say `import tinyarray.mut as ta`. On the other hand, `mut.array` means two dict lookups instead of on. Finally, realising a [Python package with submodules as a single file](https://github.com/python/cpython/issues/87533) (which is what we want for simplicity and code reuse) is quirky.
- Initially mark all newly constructed tinyarrays as mutable and freeze them upon hashing or on-demand (`freeze` method). This solution may sound a bit too clever, but it would have the advantage of keeping the API simple. This possibility is [discussed for the case of lists in the Python design FAQ](https://docs.python.org/3/faq/design.html#why-must-dictionary-keys-be-immutable), and rejected because the list elements could be mutable themselves. This, however, is not a problem for tinyarrays! Immutable objects have other uses beyond dictionary keys, for example as default values for function arguments. This occasional need would be covered by a `freeze` method - mutable as default otherwise seems useful. Detail: `tinyarray.array` would always make a copy and thus return a new mutable array. `tinyarray.asarray` would avoid a copy when possible and possibly return an immutable array.
One would also have to decide what the result should be of an operation involving two mutable arrays, and one that is mutable and one that is not. I would tend to make these immutable, except perhaps in the case when both arguments are mutable.
## Views and mutability
Some operations on NumPy arrays create view objects that create a new array object that references (a part of) the data of the original array. Examples of such operations are indexing with slices or the `transpose` method. It is possible to modify the original array’s contents through a view. Tinyarray so far does not support indexing with slices, but it has `transpose`.
Views introduce a layer of indirection and require the introduction of strides (without strides, `transpose` cannot be implemented using views). Tinyarray has so far avoided introducing both which has the benefit of keeping data structures and memory access pattern simple and compact. Both are important for tinyarray’s speed which is of crucial importance.
Anyway, the biggest benefit of views is with large arrays. A `PyVarObject` object without any payload consists of five `size_t`, that is 40 bytes on 64 bit architectures. Hence, allocating and creating a new array involves a certain ovehead. The data of a small array is typically comparable in size, so that views seem not worth it for typical (i.e. tiny) arrays.
So far, the absence of views does not break compatibility with NumPy: a copy of an immutable array behaves the same as a copy. However, if mutable tinyarrays were to be introduced, we would face the following choice:
- Accept that tinyarrays behave differently from NumPy arrays when views are involved. This is not unheard of: if `l` is a list, `l[:]` creates a view but `l[1:]` creates a copy. And tinyarray already deviates from NumPy in other ways: the numerical comparison operators (`==`, `<`, etc.) work like for tuples: otherwise tinyarrays would not be usable as keys for dictionaries.
- Implement views for tinyarrays. This would have benefits for somewhat larger arrays, but also costs in terms of storage and runtime.
## Data layout
Tinyarrays are `PyVarObjects` and use [a trick](https://discuss.python.org/t/may-types-use-pyvarobject-ob-size-to-store-arbitrary-data/24136) to reduce the storage size: the obligatory `ob_size` field is used in a clever way:
- When `ob_size >= 0`, it stores the length of a 1-dimensional array.
- When `ob_size < -1`, its absolute value stores the number of dimensions (`ndim`). The shape is stored separately.
- The meaning of `ob_size == -1` is `ndim = 0`.
This way of storing things has two advantages:
- In the common case of `ndim == 1` no shape needs to be stored. This saves one `size_t`, i.e. 8 bytes.
- When the method `Array_base::ndim_shape` (see file `array.hh`) returns the number of dimensions and shape, it is able to return a pointer to the shape even in the special case `ndim == 1`: a pointer to the `ob_size` field is returned, which corresponds to the shape!
Unfortunately, in the case where we want to store a mutability bit for each array, I do not see how to store it in `ob_size` while keeping the above optimization. The problem is not the loss of one bit for `ndim` or size, but that there is no way that `ob_size` can correspond to the shape for both mutable and immutable arrays.
A practical solution would be to use `ob_size` to store `ndim` as well as mutability. The shape would then have to be stored separately, also in the case of one-dimensional arrays. That’s probably negligible.
## Preliminary synthesis
I’d like to hear what others think is the best way to balance the above constraints.
Currently, I tend to:
- Types: Do not introduce new types. Store mutability for each new array instance.
- API: Make each new array initially mutable. Freeze upon first call of `__hash__` or when requested manually through the `freeze` method.
- Views: Do not introduce views. Accept that semantics differs from NumPy (as it does now).
- Data layout: Accept the additional `size_t` for one-dimensional arrays.
Do you see serious problems caused by the above choices?https://gitlab.kwant-project.org/kwant/tinyarray/-/issues/22Factor out object size calculation2023-02-28T16:35:27ZChristoph GrothFactor out object size calculationThere are at least three places (can be found by grepping for `ndim > 1`) there the size of the array object is computed according to the same rules. This should be factored out into a unique (inline) function.There are at least three places (can be found by grepping for `ndim > 1`) there the size of the array object is computed according to the same rules. This should be factored out into a unique (inline) function.https://gitlab.kwant-project.org/kwant/kwant/-/issues/422Option to change svd LAPACK driver2023-02-28T11:10:15ZRik BroekhovenOption to change svd LAPACK driverDefault SVD lapack driver is "gessd" which in some cases can fail to find the SVD decomposition of the hopping in `kwant.self_energy`. It would be good to have a user option to change the driver to "gesvd" which is less efficient but mor...Default SVD lapack driver is "gessd" which in some cases can fail to find the SVD decomposition of the hopping in `kwant.self_energy`. It would be good to have a user option to change the driver to "gesvd" which is less efficient but more complete.https://gitlab.kwant-project.org/kwant/tinyarray/-/issues/21Binary operator tests fail on i386 with python 3.102023-02-28T16:35:52ZEmanuele RoccaBinary operator tests fail on i386 with python 3.10Hi,
tinyarray seems to have issues with python3.10 on i386. I wonder if the problem may somehow be related to https://github.com/python/cpython/issues/82180.
This issue is tracked in Debian as https://bugs.debian.org/cgi-bin/bugreport.c...Hi,
tinyarray seems to have issues with python3.10 on i386. I wonder if the problem may somehow be related to https://github.com/python/cpython/issues/82180.
This issue is tracked in Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017051.
```
=================================== FAILURES ===================================
____________________________ test_binary_operators _____________________________
def test_binary_operators():
ops = operator
operations = [ops.add, ops.sub, ops.mul, ops.mod,
ops.floordiv, ops.truediv]
if sys.version_info.major < 3:
operations.append(ops.div)
with warnings.catch_warnings():
warnings.filterwarnings("ignore", category=RuntimeWarning)
for op in operations:
for dtype in dtypes:
for shape in [(), 1, 3, (3, 2)]:
if dtype is complex and op in [ops.mod, ops.floordiv]:
continue
a = make(shape, dtype)
b = make(shape, dtype)
> assert_equal(op(ta.array(a.tolist()), ta.array(b.tolist())),
op(a, b))
E AssertionError:
E Arrays are not equal
E
E Mismatched elements: 2 / 3 (66.7%)
E Max absolute difference: 1.11022302e-16
E Max relative difference: 1.11022302e-16
E x: array([nan+nanj, 1. +0.j, 1. +0.j])
E y: array([nan+nanj, 1. +0.j, 1. +0.j])
../../../test_tinyarray.py:375: AssertionError
______________________________ test_binary_ufuncs ______________________________
def test_binary_ufuncs():
with warnings.catch_warnings():
warnings.filterwarnings("ignore", category=RuntimeWarning)
for name in ["add", "subtract", "multiply", "divide",
"remainder", "floor_divide"]:
np_func = np.__dict__[name]
ta_func = ta.__dict__[name]
for dtype in dtypes:
for shape in [(), 1, 3, (3, 2)]:
if dtype is complex and \
name in ["remainder", "floor_divide"]:
continue
a = make(shape, dtype)
b = make(shape, dtype)
> assert_equal(ta_func(a.tolist(), b.tolist()),
np_func(a, b))
E AssertionError:
E Arrays are not equal
E
E Mismatched elements: 2 / 3 (66.7%)
E Max absolute difference: 1.11022302e-16
E Max relative difference: 1.11022302e-16
E x: array([nan+nanj, 1. +0.j, 1. +0.j])
E y: array([nan+nanj, 1. +0.j, 1. +0.j])
../../../test_tinyarray.py:396: AssertionError
```https://gitlab.kwant-project.org/kwant/kwant/-/issues/408module 'kwant.linalg._mumps' has no attribute 'dmumps'2021-10-06T11:05:07ZBhavya Bhardwajmodule 'kwant.linalg._mumps' has no attribute 'dmumps'Python Version: 3.7.8
Kwant Version: 1.4.2
```
Error--------
AttributeError Traceback (most recent call last)
<ipython-input-6-c80da766c4bb> in <module>
17 pyplot.ylabel("conductance [e^2/h]")
1...Python Version: 3.7.8
Kwant Version: 1.4.2
```
Error--------
AttributeError Traceback (most recent call last)
<ipython-input-6-c80da766c4bb> in <module>
17 pyplot.ylabel("conductance [e^2/h]")
18 pyplot.show()
---> 19 solving(model.tokwant())
<ipython-input-6-c80da766c4bb> in solving(sys)
7 energy = ie * 0.01
8 # compute the scattering matrix at a given energy
----> 9 smatrix = kwant.greens_function(sys, energy,check_hermiticity=False)
10 # compute the transmission probability from lead 0 to
11 # lead 1
~/Downloads/112358/lib/python3.7/site-packages/kwant/_common.py in inner(*args, **kwargs)
70 if sig.bind(*args, **kwargs).arguments.get(parameter_name):
71 warn()
---> 72 return f(*args, **kwargs)
73
74 return inner
~/Downloads/112358/lib/python3.7/site-packages/kwant/solvers/common.py in greens_function(self, sys, energy, args, out_leads, in_leads, check_hermiticity, params)
485 rhs = sp.bmat([[i for i in linsys.rhs if i.shape[1]]],
486 format=self.rhsformat)
--> 487 flhs = self._factorized(linsys.lhs)
488 data = self._solve_linear_sys(flhs, rhs, kept_vars)
489
~/Downloads/112358/lib/python3.7/site-packages/kwant/solvers/mumps.py in _factorized(self, a)
102 def _factorized(self, a):
103 inst = mumps.MUMPSContext()
--> 104 inst.factor(a, ordering=self.ordering)
105 return inst
106
~/Downloads/112358/lib/python3.7/site-packages/kwant/linalg/mumps.py in factor(self, a, ordering, ooc, pivot_tol, reuse_analysis, overwrite_a)
318 row, col, data)
319 else:
--> 320 self.analyze(a, ordering=ordering, overwrite_a=overwrite_a)
321
322 self.mumps_instance.icntl[22] = 1 if ooc else 0
~/Downloads/112358/lib/python3.7/site-packages/kwant/linalg/mumps.py in analyze(self, a, ordering, overwrite_a)
227
228 if dtype != self.dtype:
--> 229 self.mumps_instance = getattr(_mumps, dtype+"mumps")(self.verbose)
230 self.dtype = dtype
231
*AttributeError: module 'kwant.linalg._mumps' has no attribute 'dmumps'*
```https://gitlab.kwant-project.org/kwant/kwant/-/issues/404StabilizedModes.sqrt_hop scaling and off-diagonal entries change when adding ...2021-03-30T11:57:50ZDavid van DrielStabilizedModes.sqrt_hop scaling and off-diagonal entries change when adding lead_conservation lawsI multiply StabilizedModes.vecs by StabilizedModes.sqrt_hop (H.C.) to get a matrix related to the incoming lead modes. But sqrt_hop behaves very differently when I add a lead_conservation law like spin or particle-hole. The scaling and o...I multiply StabilizedModes.vecs by StabilizedModes.sqrt_hop (H.C.) to get a matrix related to the incoming lead modes. But sqrt_hop behaves very differently when I add a lead_conservation law like spin or particle-hole. The scaling and off-diagonal elements are very different to what I expect. See this minimal example: [sqrt_hop_snip.py](/uploads/4d8aca2e4a9b1ec332db14eb583d8944/sqrt_hop_snip.py)
What is should I expect from sqrt_hop upon adding a lead_conservation law?https://gitlab.kwant-project.org/kwant/kwant/-/issues/402Plotly 3D system plot doesn't respect aspect ratio2021-02-22T09:20:26ZBas NijholtPlotly 3D system plot doesn't respect aspect ratioPlotting this system
![image](/uploads/9e1329603b4f870a6a1d07a3d0f3814d/image.png)
using plotly results in
![image](/uploads/e5833c722d7db53feb87b70d617d5fd8/image.png)
I tried fixing it by setting the `aspectratio` on the `fig.layout...Plotting this system
![image](/uploads/9e1329603b4f870a6a1d07a3d0f3814d/image.png)
using plotly results in
![image](/uploads/e5833c722d7db53feb87b70d617d5fd8/image.png)
I tried fixing it by setting the `aspectratio` on the `fig.layout.scene` setter but that didn't work. Possibly we are running into this upstream issue https://github.com/plotly/plotly.py/issues/2511.
I managed to fix it by setting the bounding box as suggested by @anton-akhmerov:
```python
coord_min = np.min([np.nanmin(d[key].astype(float)) for d in fig.data for key in "xyz"])
coord_max = np.max([np.nanmax(d[key].astype(float)) for d in fig.data for key in "xyz"])
lim = np.abs([coord_min, coord_max]).max()
lims = dict(range=[-lim, lim])
fig.update_layout(scene=dict(xaxis=lims, yaxis=lims, zaxis=lims))
```
I was using latest `master`.https://gitlab.kwant-project.org/kwant/kwant/-/issues/400Missing imaginary unit from the definition of the source operator2021-01-26T20:39:46ZJakub ZeleznyMissing imaginary unit from the definition of the source operatorAs far as I can say, in the documentation for the Source operator, an imaginary unit is missing in the definition: the expression given in the documentation should be multiplied by i. This should be there because otherwise the commutator...As far as I can say, in the documentation for the Source operator, an imaginary unit is missing in the definition: the expression given in the documentation should be multiplied by i. This should be there because otherwise the commutator would not be Hermitian. In the source code the commutator is in fact multiplied by i, if I'm understanding it correctly.
I also don't understand why is a Hermitian conjugate of the H_i taken for the definition of the source operator. Shouldn't the Hamiltonian matrix be Hermitian?https://gitlab.kwant-project.org/kwant/website/-/issues/27Add 2020 workshop to website2021-01-22T10:54:24ZMarten ArthersAdd 2020 workshop to website2020 workshop could be added to kwant-project.org/doc/. Both the video's and the notebooks are relevant. Also, a blogpost could be written (or simply add the link to the summary already made by Anton as blogpost).2020 workshop could be added to kwant-project.org/doc/. Both the video's and the notebooks are relevant. Also, a blogpost could be written (or simply add the link to the summary already made by Anton as blogpost).https://gitlab.kwant-project.org/kwant/kwant/-/issues/399Basic pretty printing of systems is confusing2020-12-11T22:12:48ZChristoph GrothBasic pretty printing of systems is confusingIn bab68fe78033a2316b81883597ddf34c98c5f76c a method `System.__str__` was added that produces output like:
```
<InfiniteSystem with 4 sites, and 6 hoppings>
```
This feature went under my radar, but today I became aware (thanks to a con...In bab68fe78033a2316b81883597ddf34c98c5f76c a method `System.__str__` was added that produces output like:
```
<InfiniteSystem with 4 sites, and 6 hoppings>
```
This feature went under my radar, but today I became aware (thanks to a confused user of Kwant) that it's problematic. What is actually shown are the values of `self.graph.num_nodes` and `self.graph.num_edges`. This poses several problems:
- Hoppings of Kwant systems are by design Hermitian. In order to be able to query the hoppings of each site, each hopping is stored as a pair of edges of a directed compressed graph. Thus, what is typically understood as the number of hoppings would rather correspond to half that value.
- The number of sites of an infinite system does not correspond to the number of sites of the graph, since the graph contains "mirror" sites that are used to define inter-cell hoppings.
Both these points seem easy to fix. But we should also consider the planned evolution of Kwant. In our new vectorized system format the number of hoppings in the old sense is not even that easy to compute (since there can be multiple hoppings connecting the same sites).
Such pretty printed "representations" of systems must be very lossy. What is actually their purpose? To provide some useful statistics? To be able to tell different systems from each other? Something else?https://gitlab.kwant-project.org/kwant/minicourse/-/issues/3Add a post-workshop survey2020-12-02T13:37:20ZAnton AkhmerovAdd a post-workshop surveyThis is for collecting feedback, and gauging demand.This is for collecting feedback, and gauging demand.https://gitlab.kwant-project.org/kwant/minicourse/-/issues/2Plan for the first 2 sessions2020-12-01T16:11:05ZAnton AkhmerovPlan for the first 2 sessions# Meeting notes
## Phenomena:
- Quantum point contact
- Graphene pnp
- Fano factor
- AB loop (+graphene)
---
- QHE
- Topological insulators
- Superconductivity
- Multiterminal
## Kwant API:
- Builder, System
- Lattice
- Shapes
- Va...# Meeting notes
## Phenomena:
- Quantum point contact
- Graphene pnp
- Fano factor
- AB loop (+graphene)
---
- QHE
- Topological insulators
- Superconductivity
- Multiterminal
## Kwant API:
- Builder, System
- Lattice
- Shapes
- Value functions
- Transmission and scattering matrix
- Band structures
---
- Symmetry
- Scattering wave function
- Operators and densities
- Disctretizer
---https://gitlab.kwant-project.org/kwant/minicourse/-/issues/1Timeline2020-12-02T14:10:13ZChristoph GrothTimeline- [x] 11/06 Prepare an [application](#Application) and apply
- [x] Check with binder team whether they can host enough people
- [x] Need to open an issue a few weeks ahead [here](https://github.com/jupyterhub/mybinder.org-deploy/issu...- [x] 11/06 Prepare an [application](#Application) and apply
- [x] Check with binder team whether they can host enough people
- [x] Need to open an issue a few weeks ahead [here](https://github.com/jupyterhub/mybinder.org-deploy/issues/new?labels=impact&template=request_resources.md) requesting temporary resources. We should also credit binder
- [x] 11/19 Assemble the course team
- [x] 11/19 Prepare a repository and define the structure
- [x] Decide on participant/instructor ratio
- [x] 11/19 Finalize the schedule (at least rough schedule)
- [x] 11/26 Publish the event page
- Decide whether we want to ask additional questions on registration
- Open call for assistants to join
- [x] 11/26 Make a blog post and mailing list announcements
- [ ] 12/10 Prepare the materials
- [ ] 12/15 Review the materials
- [ ] 12/15 Infrastructure/software test
- [ ] 12/17 Run the event
- [ ] Debrief
- [ ] 12/19 Wrap up, update Kwant website and VSF event pagehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/397Can Discretizer benefit from Sympy's common subexpression extraction feature?2020-11-19T12:25:14ZMichael WimmerCan Discretizer benefit from Sympy's common subexpression extraction feature?Can one use `sympy.cse` to optimize the expressions that `kwant.continuum.Discretizer` generates?Can one use `sympy.cse` to optimize the expressions that `kwant.continuum.Discretizer` generates?https://gitlab.kwant-project.org/kwant/kwant/-/issues/395Improve Hamiltonian evaluation for vectorized systems2020-10-26T15:23:39ZChristoph GrothImprove Hamiltonian evaluation for vectorized systemsSo far, the new `system.VectorizedSystem` offers a `hamiltonian_submatrix` method that offers a subset of the functionality of the eponymous method of `system.System`.
This is a good first step, but we are not bound by backwards compati...So far, the new `system.VectorizedSystem` offers a `hamiltonian_submatrix` method that offers a subset of the functionality of the eponymous method of `system.System`.
This is a good first step, but we are not bound by backwards compatibility here (the new `hamiltonian_submatrix` already breaks it), since there is no legacy code that enables vectorization.
This gives as a unique opportunity to modernize the API for evaluating Hamiltonians.
Here are some problems with the old API:
- It's incompatible with ND-systems.
- It's not possible to selectively evaluate terms (for example only terms that depend on a particular parameter could be of interest).
- By default, a dense matrix is returned (#244).
- It's impossible to act with the Hamiltonian on a vector without creating a sparse matrix in memory.
- `inter_cell_hopping` may return non-square matrices.vectorization