kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/-/issues2020-10-26T15:23:39Zhttps://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.vectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/393Improve user experience when dealing with densities2020-10-23T15:46:27ZChristoph GrothImprove user experience when dealing with densitiesThe original Kwant made it quite easy to define TB systems in terms of sites and to evaluate transport properties like transmission probabilities between leads. In this workflow low-level systems and their inner workings were an impleme...The original Kwant made it quite easy to define TB systems in terms of sites and to evaluate transport properties like transmission probabilities between leads. In this workflow low-level systems and their inner workings were an implementation detail of Kwant.
When the operator module was added, it was natural for it to deal with low-level systems. However this meant that suddenly the user was exposed to details of low-level systems like the order of sites and their indices.
We would like to provide an intuitive way to handle densities, and the [vectorization effort](https://gitlab.kwant-project.org/kwant/kwant/-/milestones/9) seems like a good moment to introduce a new improved API because we have to [review operators for ND systems](#333) anyway.
To proposals exist that offer different solutions to this problem:
- #9
- #65
I propose to discuss the topic generally here and decide on a course of action. At the end of the discussion, one of the above two issues could be updated, and the other closed (along with this one).vectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/379Remove link to INAC website2020-05-13T15:37:22ZJoseph WestonRemove link to INAC websiteThe link to @waintal's homepage is [causing the linkcheck build step to fail](https://gitlab.kwant-project.org/kwant/kwant/-/jobs/120706).
It seems that http://inac.cea.fr is down and has been for a few weeks. We should either point to ...The link to @waintal's homepage is [causing the linkcheck build step to fail](https://gitlab.kwant-project.org/kwant/kwant/-/jobs/120706).
It seems that http://inac.cea.fr is down and has been for a few weeks. We should either point to Xavier's actual homepage or remove the link.https://gitlab.kwant-project.org/kwant/kwant/-/issues/372Use structural subtyping for defining interfaces to the different parts of Kwant2020-04-01T16:46:58ZJoseph WestonUse structural subtyping for defining interfaces to the different parts of Kwant## Problem definition
In principle Kwant has several more or less independent components separated by interfaces: Builder, System, solvers, plotter
In practice the specific interfaces that are used are only loosely defined, and it is q...## Problem definition
In principle Kwant has several more or less independent components separated by interfaces: Builder, System, solvers, plotter
In practice the specific interfaces that are used are only loosely defined, and it is quite challenging (even for one well-versed in the internals of Kwant) to create new classes which adhere to the correct interface.
Take, for example `kwant.system.FiniteSystem` which can, in principle, be plotted by `kwant.plot` if it provides a `pos` method (this is not even documented in the docstring of `plot`; it just says that the `sys` parameter may be a `Builder` or `system.Finitesystem`). However, if the leads do not provide a `symmetry` attribute that has the interface of a `kwant.lattice.TranslationalSymmetry` then they are simply not plotted.
This is not documented in `plot`. Even if it were, having ad-hoc interfaces defined in docstrings is probably not the way to go.
In practice people use Kwant as a monolithic package, and it is often unacceptable to e.g. be able to define custom system classes but be unable to plot them properly.
## Proposed Solution
I propose to use structural subtyping a la [PEP 544](https://www.python.org/dev/peps/pep-0544) to allow use to more precisely specify the interfaces required by the different parts of Kwant.
We can either wait until we can rely on Python 3.8, and make use of [`typing.Protocol`](https://docs.python.org/3/library/typing.html#typing.Protocol) or roll our own with `__subclass_hook__`.https://gitlab.kwant-project.org/kwant/kwant/-/issues/368Using smatrix on a system with a SelfEnergyLead fails2024-01-09T20:07:17ZJoseph WestonUsing smatrix on a system with a SelfEnergyLead failsI don't have time to make an example right now, but if you construct a system that has a `kwant.builder.SelfEnergyLead` as one of the leads, and call `kwant.smatrix` on it Kwant will raise an `AttributeError` because the `SelfEnergyLead`...I don't have time to make an example right now, but if you construct a system that has a `kwant.builder.SelfEnergyLead` as one of the leads, and call `kwant.smatrix` on it Kwant will raise an `AttributeError` because the `SelfEnergyLead` does not have a `modes` method.
IMO this is a bug. As long as you have at least 1 lead that has `modes`, I would expect everything to work.
A naïve fix is simple: simply evaluate the self-energy of the lead and add it to the scattering region Hamiltonian.
What is a bit trickier is how to handle lead numbering. Imagine I had 3 leads attached (0, 1, 2) and lead 1 is a self-energy lead.
When asking for submatrices of the scattering matrix we would be "unable" to use lead index 1, as we have no way of getting the scattering matrix elements to the SelfEnergyLead (because it does not have `modes` defined).
What we could do is raise an exception if `smatrix` is used and there is a `SelfEnergyLead` and no `in_lead` and `out_leads` have been provided, notifying the user that they must specify this, omitting the self-energy lead. AFAICT this would solve the numbering problem.https://gitlab.kwant-project.org/kwant/kwant/-/issues/367Treat deprecation warnings as errors in the tests2020-03-20T17:24:34ZJoseph WestonTreat deprecation warnings as errors in the tests#366 highlights that our tests do not catch a certain subset of potential bugs that (IMO) they ought to.
One way to fix this specific class of bugs (where we are using deprecated API) is to make deprecation warnings errors in the tests....#366 highlights that our tests do not catch a certain subset of potential bugs that (IMO) they ought to.
One way to fix this specific class of bugs (where we are using deprecated API) is to make deprecation warnings errors in the tests.
I haven't looked but I am almost certain pytest can be configured to do this.
~"Needs Discussion" because we might also catch lots of cruft with this.https://gitlab.kwant-project.org/kwant/kwant/-/issues/365Keep separate testing images for "master" and "stable"2020-03-30T12:56:20ZJoseph WestonKeep separate testing images for "master" and "stable"Currently we test against the different supported environments (Debian / Ubuntu / Conda on Debian) by having separate Docker images, which are stored [in the container registry](https://gitlab.kwant-project.org/kwant/kwant/container_regi...Currently we test against the different supported environments (Debian / Ubuntu / Conda on Debian) by having separate Docker images, which are stored [in the container registry](https://gitlab.kwant-project.org/kwant/kwant/container_registry).
There is a manual job that can be triggered to build these images (from the Dockerfiles in `docker/`), and which then pushes the images to the registry.
However we do not currently do any kind of versioning of these images. Each time the image-build jobs are run they overwrite whatever images are currently in the registry.
This is not great, as in principle `stable` and `master` need different testing environments. For example, `stable` should work with whatever the minimum requirements were at the time the last *minor* Kwant version was released. We are, however, allowed to update the minimum requirements of `master` (e.g. if the supported OS's bumped the package versions in their repos). Currently, for example, we are not actually testing `stable` against the minimum requirements as stated in the documentation (in the state the documentation is on `stable).
Fixing this is in principle quite simple, but comes with its own problems.
In the `.gitLab-ci.yml` file there are lines like this:
```
.ubuntu-env: &ubuntu_env
image: gitlab.kwant-project.org:5005/kwant/kwant/ubuntu
```
We would have to modify these lines and stick a `:stable` or something on the end, like:
```
.ubuntu-env: &ubuntu_env
image: gitlab.kwant-project.org:5005/kwant/kwant/ubuntu:stable
```
Simple enough, right?
Except that whenever we merge `stable` into `master` (or vice versa) we would have to ensure that these lines are not taken over (i.e. that we do not have the `:stable` images used by `master` or vice versa). Git's default merge strategy will, unfortunately, work against us.
In principle only a few people are merging `master` and `stable` together, and as long as they are aware of this it should "all be good" (and if we mess up it's easy to fix in a new commit), but it still makes me a little uneasy.
It is also not possible (AFAIK) to tell git to apply a particular merge strategy (`ours` in this case) to individual files.https://gitlab.kwant-project.org/kwant/kwant/-/issues/364Consider switching to "src" package layout and using "tox" for test running2020-03-18T17:53:42ZJoseph WestonConsider switching to "src" package layout and using "tox" for test runningWhen hacking on Kwant it is recommended [by the Kwant docs](https://kwant-project.org/contribute#setting-up-for-development) to use `python setup.py build_ext --inplace && pytest` for testing.
There are a couple of problems I have obser...When hacking on Kwant it is recommended [by the Kwant docs](https://kwant-project.org/contribute#setting-up-for-development) to use `python setup.py build_ext --inplace && pytest` for testing.
There are a couple of problems I have observed with this workflow:
1. the `build_ext --inplace` step is kind of non-standard, and if done incorrectly (e.g. by omitting the `--inplace`) then `python -c 'import kwant'` complains about not importing Kwant from the correct place (this has confused me more times than I care to mention)
2. placing the `.c` files next to the source an be problematic. `Cython` is not re-run if the associated `.pyx` file has not changed, but if we are using different versions of Cython, or targeting different CPython APIs (can happen when jumping around between `stable`/`master`) then the `.c` files are *still* not regenerated.
3. locally testing against different environments becomes a pain (manually deactivating / reactivating different Conda environments / whoops I just wasted 10 minutes because I was in the wrong environment)
I believe that points 1 and 3 can be addressed by using [the `src` layout](https://hynek.me/articles/testing-packaging/) (i.e. have the Kwant source code under `src/kwant` rather than directly in `kwant`) and by using an environment-aware test-runner such as [tox](https://tox.readthedocs.io/en/latest/) (which also has support for Conda environments).
I am not sure if this will address 2, but 2/3 ain't bad.https://gitlab.kwant-project.org/kwant/kwant/-/issues/355Vectorization of builders2020-05-07T20:34:58ZChristoph GrothVectorization of buildersCurrently, builders store the Hamiltonian as a Python dictionary of adjacency lists (interleaved with values), as described in a comment in `builder.py`:
```
# For a given `tail` site, H[tail] is a list alternately storing
# head...Currently, builders store the Hamiltonian as a Python dictionary of adjacency lists (interleaved with values), as described in a comment in `builder.py`:
```
# For a given `tail` site, H[tail] is a list alternately storing
# heads and values. (The heads occupy even locations followed by the
# values at odd locations.) Each pair of entries thus describes a single
# directed edge of the graph.
```
Dealing with a system of N sites requires O(N) Python operations. With the vectorization of low-level systems, this can become a bottleneck, or at least a nuisance.
Since we need update the builder finalization code anyway (so that builders with more than a single translational symmetry can be finalized), why not try to solve both problems in one go and vectorize builders?
Fortunately, in terms of API (almost) nothing needs to change. Already now builders offer a vectorized interface in that many elements can be set with a single Python operation: a builder can be indexed with a sequence of sites. A natural evolution of this would be to also allow sitearrays and "tuple arrays", i.e. 2-tuples of sitearrays. This would allow to vectorize `shape`, `neighbors`, and `fill` and as such most old user scripts, without changing anything on the user side.
The more complicated part is reworking the data structures used internally by builders to efficiently support vectorization. Let’s try to analyze in a language-agnostic way what data structure would be best suited:
- We should optimize for a small number of site families, just like we already do in the new low-level format. This means that instead of storing a single graph indexed by (pairs of) sites, we could store separate graphs for each pair of families. These vertices of these graphs would be indexed by tags. I think that we could restrict valid tags to sequences of numbers without loosing anything. Together, this means that what we need is an efficient data structure to store graphs over vertices that are identified by sequences of numbers.
- We could also optimize for a small number of different values, since this is the most common usage by far. Ideally, the use case of having a different constant value for each site/hopping would be still viable, but I am not even sure if such systems were ever made.
A hash table of adjacency lists still seems the right data structure, only that it should be vectorized and it would be indexed by sequences of numbers (of same length) and not by generic Python objects.
I can’t see how to implement something like this efficiently in pure Python, but writing it as a C extension is not a very big deal - much simpler then, say, writing tinyarray. Perhaps, actually, a vectorized dictionary with keys that are sequences of numbers would be a useful addition to tinyarray?vectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/352Idea: reduce the number of options through "configuration variables"2020-02-27T10:59:56ZChristoph GrothIdea: reduce the number of options through "configuration variables"Some Kwant functions take options that are rarely set, and if so, they are often set for a whole session. The prime example is the `show` argument to all plotting functions, but there's also `dpi`, `fig_size`, and perhaps also `cmap` fo...Some Kwant functions take options that are rarely set, and if so, they are often set for a whole session. The prime example is the `show` argument to all plotting functions, but there's also `dpi`, `fig_size`, and perhaps also `cmap` for example. Outside of plotter, there are parameters to the MUMPS solver like `nrhs` that are very rarely set, because it's cumbersome to do so.
Another problem with these options is that API-functions that call other API-functions (like `plotter.current` that calls `plotter.streamplot` and `plotter.interpolate_current`) need to re-expose options if the user is able to set them, or pass on kwargs. This leads to the kind of kwargs-hell known from matplotlib.
Now we could replace these options with global variables, and that could be done even in a backwards-compatible way (because the options would remain, and could even have precedence). Something like this:
```
old_value = kwant.plotter.show
kwant.plotter.show=False
# code that is executed with show set to False.
kwant.plotter.show=old_value
```
But this solution has several grave problems. Notably, there's no error when mistyping, and it's a mess when different configuration values are used throughout the same program. With async/multithreaded programs it becomes unmanageable.
Here is a possible solution that has been haunting me for some time: we could implement a special type of configuration variables that would emulate [dynamic scope from Lisp](https://www.gnu.org/software/emacs/emacs-paper.html#SEC17). The syntax could be taken over verbatim from the [contextvars stdlib module](https://docs.python.org/3/library/contextvars.html). In fact, contextvars could (and probably should) be used internally to make the configuration vars async-proof.
```
token = kwant.plotter.show.set(False)
# code that is executed with show set to False.
kwant.plotter.dpi.reset(token)
```
However, that's a bit on the heavy side. There could be also, additionally, a lighter context-manager-based syntax:
```
with kwant.plotter.show.set(False):
# code that is executed with show set to False.
```
(The stdlib context vars lack the context-manager syntax, but only because it was initially not deemed necessary for this low-level feature: https://mail.python.org/archives/list/python-ideas@python.org/thread/E4BB2WFMSC7D2GVOT4AFW3EBDY57HNQA.)
We could start slowly only using this for the likes of `show`, but I believe that the above could be actually useful for most optional arguments to functions. The configuration variables could be even under the scope of the function that they belong to, e.g.:
```
with plotter.streamplot.cmap.set(something):
plotter.current(...)
```
Configuration options could be also made to inherit from each other when useful. For example, `kwant.plotter.streamplot.cmap` could inherit from `kwant.plotter.cmap`. This would allow to easily use one colormap for all streamplots, but another one for all other plots.
While this may seem a little bit technical and complicated, the usage is very simple, and this change would be fully backwards compatible.
---
This may deserve to be turned into a separate module on PyPI, but it's also small enough to be included into Kwant at least initially.https://gitlab.kwant-project.org/kwant/kwant/-/issues/343Consider adding a global switch for vectorization2020-02-13T09:59:07ZAnton AkhmerovConsider adding a global switch for vectorizationRight now there's a per-builder switch `vectorized=False`. @slavoutich correctly observed that vectorized code is unlikely to be mixed with unvectorized code, so in order to reduce boilerplate and ease the transition to the vectorized fo...Right now there's a per-builder switch `vectorized=False`. @slavoutich correctly observed that vectorized code is unlikely to be mixed with unvectorized code, so in order to reduce boilerplate and ease the transition to the vectorized format we may instead implement this flag as a global configuration option and instead require that the user calls `kwant.enable_vectorization()`.vectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/302Minimally invasive vectorization of Kwant2020-10-23T15:46:27ZChristoph GrothMinimally invasive vectorization of KwantHere's a plan to vectorize Kwant with a minimal amount of changes. The idea is that this is something that can be coded quickly, but is still very useful, and comprises a useful step forward towards more generalized systems/operators.
...Here's a plan to vectorize Kwant with a minimal amount of changes. The idea is that this is something that can be coded quickly, but is still very useful, and comprises a useful step forward towards more generalized systems/operators.
In the following, I only speak about finite systems. Infinite systems should be a straightforward generalization.
Vectorization of low-level systems
----------------------------------
A kwant (low-level) system provides two things:
(1) A graph whose nodes (=sites) and edges (=hoppings) are densely numbered, each starting with zero.
(2) A way to obtain an element of the Hamiltonian matrix that is identified by two site indices and may further depend on system parameters.
I propose to extend the low-level system API in the following way:
- We introduce numbered "value kinds". (I'm looking for a better name, how about "part"? I don't want to say "term", because of the limitation that each site/hopping belongs only to one value kind.) Each site and each hopping has exactly one value kind associated with it. This association is exposed by the API in two ways: two arrays that store the value kind index for each site and hopping, and for each value kind, a sequence of the associated site/hopping indices.
(We probably want to restrict a given value kind to either sites or hoppings. We even might have two separate numberings, one for site value kinds and one for hopping value kinds, but then, we may also have a single common numbering. This is a detail to be discussed.)
- We add a new method that allows to query a single value kind in a vectorized way for all the associated sites/hoppings at once. That method takes the value kind index, and system parameters. It returns a dense 3D array of the shape (n, a, b) where n is the number of sites/hoppings that share the value kind, and (a, b) is the size of the matrix element. Obviously this implies that all values that share the same kind have the same matrix shape (for the same parameters).
- For each value kind, we list the necessary parameters.
Observe that the above allows to implement `hamiltonian_submatrix` efficiently. It also preserves the numbering of sites and hoppings, so that existing user scripts continue to work unchanged.
Still, to simplify our lifes, we might want to deprecate `hamiltonian_submatrix`, and even break support for calling it in the fully general way. In practice, `hamiltonian_submatrix` is either called for the full system, or for the unit cell and the inter-cell hopping of a lead.
Vectorized finalized builders
-----------------------------
How to implement the above API for finalized builders?
We introduce a new `SiteArray` class that associates multiple tags with a single site family. It's API is like the one of `Site`, but in plural (except for `family`). So, there's `tags`, and `positions` that each return a sequence. Note that for the common Bravais lattices, both `tags` and `positions` can return a single dense 2D array of numbers.
From the user's perspective, vectorized builders are created in exactly the same way. The only difference is that value functions receive `SiteArray` instances instead of `Site`, and return arrays of values. In addition, vectorization needs to be enabled somehow. This could be done with a global switch, e.g. by calling `kwant.vectorize()`.
Of course finalized builders have to provide the new vectorized low-level system API as well as the old one. Observe that providing the old one, i.e. the `hamiltonian` method poses no problem. We can keep the old code and only adapt it very slightly to call vectorized value functions with site arrays of length one.
The vectorized evaluation interface can be also provided efficiently. Note that builder is free to classify values as value kinds within the constraints imposed by the low level system API (i.e. compatible matrix sizes). So, it makes sense to classify as one value kind all sites or hoppings that share the same value function *and* in addition share the same site family (pair). For example, for graphene with one kind of onsite value function and one hopping value function, there will be two kinds of onsite values (one for each site family), and one or two types of hopping kinds. (That depends on whether the user has specified only A->B kind of hoppings or also B->A hoppings. IIRC builder will remember the one that has been set.) The Hermitian conjugate opposite hoppings can be treated with the same approach as currently.
Constant values of the same shape that are defined on the same site families should be probably also classified as a single kind of value. If we want, we can treat the case where all of the matrices are equal specially, for example by adopting a storage convention that is similar to NumPy's broadcasting, i.e. instead of storing 100 times the same onsite matrix (`[M, M, M, ...]`) we store it just once (`[M]`) in a sequence of length 1.
Vectorized low-level systems should expose a `site_arrays` attribute that contains a sequence of `SiteArray` instances, that contains the same information as `sites` today, but using drastically less Python objects. The old `sites` attribute will continue to exist for backwards compatibility, but it could be made to create site objects on-demand, so that they don't have to be stored.
So, when the request arrives (by the low-level API) to evaluate the Hamiltonian for a given value kind, the finalized builder has to get hold of the necessary site arrays before it can call the user-provided value function. These can be built on-demand efficiently by a piece of Cython code or perhaps even by clever usage of NumPy.
Comments
--------
The above does not include any vectorization of the `Builder` class, that still contains a dictionary with individual sites as keys. So construction and finalization of builders won't be any faster. Speeding up builders is a separate project.
I wrote here previously:
> We can consider making `Site` a derived class of `SiteArray`.
I no longer think that this is a good idea. Instead, it seems much more natural and useful if site arrays are (fancy-indexable) sequences of sites. (However, exposing the sequence API is something that is optional and can be postponed.) This means, that unlike sites, site arrays should not be two-tuples of family and tag(s).
`SiteArrays` and `Sites` could be moved to `kwant.system` at this occasion.
If we want to implement the code that assembled the `SiteArrays` upon evaluation of a finalized builder in Python using NumPy, we may have to modify the internals of `graph.CGraph`, at least such that it exposes the arrays it stores as NumPy arrays. Currently the arrays are simply C pointers to memory. That was not done initially, because of limitation of Cython that have disappeared since. It can well be that the `graph` submodule can be drastically simplifed or even replaced by something else.https://gitlab.kwant-project.org/kwant/kwant/-/issues/277add zenodo to documentation2019-03-01T16:37:01ZAnton Akhmerovadd zenodo to documentationI can think of two places:
- RELEASE.rst
- Citing (needs a discussion of how to describe it)I can think of two places:
- RELEASE.rst
- Citing (needs a discussion of how to describe it)Kwant 1.4.xhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/273Use system.parameters in ensuring that there are no unecessary arguments2019-02-12T18:29:53ZJoseph WestonUse system.parameters in ensuring that there are no unecessary argumentsPrior [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/275#note_23697).Prior [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/275#note_23697).https://gitlab.kwant-project.org/kwant/kwant/-/issues/249Design for Plotly plotter2019-12-20T09:56:34ZJoseph WestonDesign for Plotly plotterThis issue is a summary of the discussions had between @kel85uk and @jbweston, @anton\-akhmerov, and @michaelwimmer.
Any interested parties should comment on the appropriate threads belowThis issue is a summary of the discussions had between @kel85uk and @jbweston, @anton\-akhmerov, and @michaelwimmer.
Any interested parties should comment on the appropriate threads belowPlotly PlotterKelvin LohKelvin Lohhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/247Avoid unreadable text representations of lattices.2019-02-09T22:04:35ZChristoph GrothAvoid unreadable text representations of lattices.Here's is something that I come accross again and again. What's more, it's a question that it seems will remain relevant even when we redesign systems, so we can as well discuss it here.
The problem is that textual representation of la...Here's is something that I come accross again and again. What's more, it's a question that it seems will remain relevant even when we redesign systems, so we can as well discuss it here.
The problem is that textual representation of lattices are awfully long. The most awful common case is probably:
```
>>> lat = kwant.lattice.honeycomb()
>>> print(lat.neighbors())
[HoppingKind((0, 1), kwant.lattice.Monatomic([[1.0, 0.0], [0.5,
0.8660254037844386]], [0.0, 0.0], '0', None), kwant.lattice.Monatomic([[1.0,
0.0], [0.5, 0.8660254037844386]], [0.0, 0.5773502691896258], '1', None)),
HoppingKind((0, 0), kwant.lattice.Monatomic([[1.0, 0.0], [0.5,
0.8660254037844386]], [0.0, 0.0], '0', None), kwant.lattice.Monatomic([[1.0,
0.0], [0.5, 0.8660254037844386]], [0.0, 0.5773502691896258], '1', None)),
HoppingKind((-1, 1), kwant.lattice.Monatomic([[1.0, 0.0], [0.5,
0.8660254037844386]], [0.0, 0.0], '0', None), kwant.lattice.Monatomic([[1.0,
0.0], [0.5, 0.8660254037844386]], [0.0, 0.5773502691896258], '1', None))]
```
Trying to explain to someone that hopping kinds are actually very simple is doomed to fail!
This could be resolved by printing names of the lattices instead of the lattices. But for that to be useful, names should be unique inside a session, and also survive pickling and unpickling (so that different nodes in a parallel computation share the same lattice names).
But this already shows the problem: what if I try to unpickle two different lattices that share the same name?
There is no fully satisfactory solution to this problem. There is no way to have a globally unique and nice (compact, human readable) naming scheme. But perhaps we can still improve on the current situation? Here's what I propose:
* Introduce a global (at the level of an interpreter instance) registry of names. That could have the form of two weakref dictionaries:
* One mapping site families to names. It's purpose is to allow automatically assigning names to site families.
* One mapping names to sets of families. It's purpose is to track the multiple use of names.
* Assign names by default, thus enforcing that a site family always has a name. If no name is provided, assign that first one of, say, "square0", "square1", etc. that is unused. If a name is provided, use it, but warn if it is already used for a different family.
* When printing a site family, show only the name, but add a note if that name is not unique, like this: "<site family a (name is not unique!)>"
I would expect that names that are not unique would almost never occur in practice, but I think that we still have to support them to avoid problems in corner cases.
What do you think? Do you have a better idea?futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/242Improve symmetry interface2018-11-26T13:07:38ZAnton AkhmerovImprove symmetry interfaceRight now verifying that the discrete symmetry is broken requires some low-level code:
```python
sym = syst.discrete_symmetry(params=params)
h = syst.hamiltonian_submatrix(sparse=True, params=params)
# replace with "h = syst.cell_hamilt...Right now verifying that the discrete symmetry is broken requires some low-level code:
```python
sym = syst.discrete_symmetry(params=params)
h = syst.hamiltonian_submatrix(sparse=True, params=params)
# replace with "h = syst.cell_hamiltonian(...); t = syst.inter_cell_hopping(...)"
# if the system is infinite
sym.validate(h)
```
Because this is one of the important operations, we should probably simplify it.https://gitlab.kwant-project.org/kwant/kwant/-/issues/241Make system parameter names a public API2019-02-14T16:17:07ZAnton AkhmerovMake system parameter names a public APIParameters are great, let's have more of them!
Specifically, we could make the system parameters more discoverable by considering the parameters that the system depends on a public property. The implementation would be as easy as loopin...Parameters are great, let's have more of them!
Specifically, we could make the system parameters more discoverable by considering the parameters that the system depends on a public property. The implementation would be as easy as looping over the `onsites` and `hoppings` and doing a set join on these.
We could then use those to provide a rich representation, e.g. `system with 2 leads and 100 sites that depends on ('mu', 't')`.Kwant 1.4Joseph WestonJoseph Westonhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/240Trying to define an operator using a system with no sites gives a confusing e...2019-02-12T18:42:39ZAnton AkhmerovTrying to define an operator using a system with no sites gives a confusing error messageTo reproduce:
```python
>>> import kwant; kwant.operator.Density(kwant.Builder().finalized(), [[1, 0], [0, 1]]) ...To reproduce:
```python
>>> import kwant; kwant.operator.Density(kwant.Builder().finalized(), [[1, 0], [0, 1]])
...
ValueError: Single `onsite` matrix provided, but there are different numbers of orbitals on different sites
```
Should we perhaps just refuse to finalize a system with no sites?futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/237name of Builder.substitute2018-10-12T17:55:55ZAnton Akhmerovname of Builder.substituteThe method name `Builder.substitute` may give an impression that the parameter name substitutions are done in-place. Instead this operation returns a copy (as it probably should).
We should *consider* if there is a less ambiguous name b...The method name `Builder.substitute` may give an impression that the parameter name substitutions are done in-place. Instead this operation returns a copy (as it probably should).
We should *consider* if there is a less ambiguous name before %"Kwant 1.4".Kwant 1.4Anton AkhmerovAnton Akhmerov