kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/-/issues2019-02-09T22:04:36Zhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/268Improving treatment of leads in flux algorithm2019-02-09T22:04:36ZJoseph WestonImproving treatment of leads in flux algorithmCurrently the flux algorithm is limited to leads where a single unit cell is connected. We can this trivially determine if there are any cycles (and hence any gauge contraints imposed by the leads). This limitation is largely due to the ...Currently the flux algorithm is limited to leads where a single unit cell is connected. We can this trivially determine if there are any cycles (and hence any gauge contraints imposed by the leads). This limitation is largely due to the fact that we did not do an extensive literature review to see if the problem has a known solution.
A bit of googling revealed this paper: https://dl.acm.org/citation.cfm?id=28401 (Testing for cycles in infinite graphs with periodic structure). I didn't read it yet, but it may provide a satisfactory solution.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/267Slow performance of gauge computation2019-05-09T12:19:55ZAnton AkhmerovSlow performance of gauge computationFor some reason gauge fixing is extremely slow in CI (see [the logs](https://gitlab.kwant-project.org/kwant/kwant/-/jobs/45637)):
```
========================== slowest 10 test durations ===========================
900.51s call kwan...For some reason gauge fixing is extremely slow in CI (see [the logs](https://gitlab.kwant-project.org/kwant/kwant/-/jobs/45637)):
```
========================== slowest 10 test durations ===========================
900.51s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[2-honeycomb-half-ring]
413.08s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[3-honeycomb-half-ring]
137.30s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[3-square-half-ring]
62.77s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[2-honeycomb-circle]
60.67s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[3-honeycomb-circle]
31.25s call kwant/physics/tests/test_gauge.py::test_phases[cubic-finite-3]
20.35s call kwant/physics/tests/test_gauge.py::test_phases[cubic-finite-2]
17.62s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[3-square-circle]
15.78s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[3-honeycomb-rectangle]
10.37s call kwant/physics/tests/test_gauge.py::test_minimal_cycle_basis[2-honeycomb-rectangle]
================== 389 passed, 2 warnings in 1767.99 seconds ===================
```
The same tests don't take any significant time on my laptop, so this might be a faulty configuration in CI. Still if it is something unrelated to CI (misconfigured compiler or anything alike), this could be serious enough to hold off releasing the feature.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/230Documentation links broken2019-02-09T22:09:32ZSybren ZwetslootDocumentation links brokenThe [source] links on several of the operator pages are broken.
See for example:
https://kwant-project.org/doc/1/reference/generated/kwant.operator.Density
https://kwant-project.org/doc/1/reference/generated/kwant.operator.CurrentThe [source] links on several of the operator pages are broken.
See for example:
https://kwant-project.org/doc/1/reference/generated/kwant.operator.Density
https://kwant-project.org/doc/1/reference/generated/kwant.operator.Currentfuturehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/189Check for `ModuleNotFoundError` rather than the more general `ImportError` wh...2019-02-09T23:05:41ZJoseph WestonCheck for `ModuleNotFoundError` rather than the more general `ImportError` when sensibleIn `plotter` and `continuum` we check for the presence of modules by wrapping their imports in a try-except, where we catch `ImportError`.
`ImportError` is raised whenever there was a problem importing the module. Depending on our usage...In `plotter` and `continuum` we check for the presence of modules by wrapping their imports in a try-except, where we catch `ImportError`.
`ImportError` is raised whenever there was a problem importing the module. Depending on our usage, it may be more idiomatic to raise `ModuleNotFound` error instead.
This is the case *if* other errors while importing the modules should bubble up further.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/165Speed up 'plotter.interpolate_current'2020-10-22T08:30:00ZJoseph WestonSpeed up 'plotter.interpolate_current'Presently there is a tight Python loop that is the bottleneck in interpolating the current. This could be sped up by moving the loop to Cython and using a `cdef` function for the smoothing.Presently there is a tight Python loop that is the bottleneck in interpolating the current. This could be sped up by moving the loop to Cython and using a `cdef` function for the smoothing.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/137Factor the Brillouin zone logic out of wraparound.2019-02-09T23:09:20ZAnton AkhmerovFactor the Brillouin zone logic out of wraparound.Calculation of a Brillouin zone probably belongs in `lattice`, but whether it should play with `TranslationalSymmetry` or `PolyatomicLattice` depends on #73. Also we should probably keep in mind further symmetry generalizations planned f...Calculation of a Brillouin zone probably belongs in `lattice`, but whether it should play with `TranslationalSymmetry` or `PolyatomicLattice` depends on #73. Also we should probably keep in mind further symmetry generalizations planned for #38.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/124Test current interpolation in 3-d2020-10-22T09:04:45ZChristoph GrothTest current interpolation in 3-d(and make sure it works!)
For completeness, we should also make sure it works in 1-d.(and make sure it works!)
For completeness, we should also make sure it works in 1-d.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/123Generalize HoppingKind2019-02-09T22:04:34ZChristoph GrothGeneralize HoppingKindCurrently, a `HoppingKind` instance corresponds to all hopping between `a` and `b` such that
```
a.family is hk.family_a
b.family is hk.family_b
a.tag - b.tag == hk.delta
```
This cannot describe hoppings between lattices with differin...Currently, a `HoppingKind` instance corresponds to all hopping between `a` and `b` such that
```
a.family is hk.family_a
b.family is hk.family_b
a.tag - b.tag == hk.delta
```
This cannot describe hoppings between lattices with differing but commensurate periods like `square(1)` and `square(2)`.
I propose to modify this as follows:
```
b.tag = a.tag * hk.factor - hk.delta
```
The factor would be one by default and as such this enhancement is backwards-compatible.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/81providing params via system interface2020-05-08T21:02:13ZAnton Akhmerovproviding params via system interfaceAfter #77 the call signature of `kwant.smatrix` and other consumers of `System` have a rather lengthy call signature: `kwant.smatrix(syst, energy, args=..., params=...)`. It is counter-intuitive to supply arguments that the system consum...After #77 the call signature of `kwant.smatrix` and other consumers of `System` have a rather lengthy call signature: `kwant.smatrix(syst, energy, args=..., params=...)`. It is counter-intuitive to supply arguments that the system consumes using awkward syntax and via an unrelated function.
I propose an alternative pathway for doing so. A method `System.update_parameters(*args, **kwargs)` that will return a shallow copy of the system that stores its arguments and keyword arguments such that the user doesn't need to provide them elsewhere. Example usage:
```python
[kwant.smatrix(syst.update_parameters(0, B=5)) for B in fields]
```
Extra considerations
* `System`s already have a method `precalculate` that returns a modified shallow copy.
* This change is fully backwards-compatible (old way of providing parameters would still work).futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/73Base lattices on the concept of symmetry2019-02-09T22:09:31ZChristoph GrothBase lattices on the concept of symmetryKwant contains both the concept of spatial symmetries and the concept of regular (Bravais) lattices. Both are related: `TranslationalSymmetry` works only with the lattices as defined in the `lattice` module.
This integration could be...Kwant contains both the concept of spatial symmetries and the concept of regular (Bravais) lattices. Both are related: `TranslationalSymmetry` works only with the lattices as defined in the `lattice` module.
This integration could be improved. For example, the flood-fill code of `shape()` in the lattice module and `fill()` in the builder module is similar. It should be possible to redefine lattices on top of (translational?) symmetries, and factor out as much common code as possible.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/60When plotting a detached lead, provide a way to plot multiple unit cells2019-02-09T22:19:57ZChristoph GrothWhen plotting a detached lead, provide a way to plot multiple unit cellsCurrently this is not possible, and [this is a problem](https://www.mail-archive.com/kwant-discuss@kwant-project.org/msg00974.html). As a possible solution, the value of the option `num_lead_cells` could be also honored when plotting a ...Currently this is not possible, and [this is a problem](https://www.mail-archive.com/kwant-discuss@kwant-project.org/msg00974.html). As a possible solution, the value of the option `num_lead_cells` could be also honored when plotting a detached lead.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/54Parallel MUMPS solver with MPI2019-02-09T22:19:57ZJoseph WestonParallel MUMPS solver with MPIMUMPS supports parallelism using MPI, but Kwant currently only uses it in sequential mode.
#### [MUMPS documentation](http://mumps.enseeiht.fr/doc/userguide_5.0.2.pdf)
There are several issues to consider:
#### parallelizing the...MUMPS supports parallelism using MPI, but Kwant currently only uses it in sequential mode.
#### [MUMPS documentation](http://mumps.enseeiht.fr/doc/userguide_5.0.2.pdf)
There are several issues to consider:
#### parallelizing the "solve" step
Reasonably standard. Controlling this will require looking in section 5.1.3 of the documentation
#### constructing the Hamiltonian
MUMPS supports several ways of specifying the matrix to solve for (see section 5.2 and 5.2.2 of the documentation)
1. full matrix is provided on rank 0 (MUMPS will then split the matrix across the available cores)
2. matrix is pre-split by the application that calls MUMPS
The first method is much easier to implement than the second, as the second would require hooking the
Builder into MPI (a mess). One could imagine the following way of operating:
```python
comm = ... # MPI communicator to parallelize over
syst = make_system().finalized()
parallel_mumps_solver.solve(syst, comm=comm) # not the actual API, just an example
```
The problem with this is that the system is actually constructed on all cores, even though MUMPS would
only use the system on core 0! One can get around this by requiring the user to construct the system
only on rank 0:
```python
comm = ... # MPI communicator to parallelize over
syst = None
if comm.rank == 0:
syst = make_system().finalized()
# note that *everyone* must call `solve` in order to avoid a deadlock
parallel_mumps_solver.solve(syst, comm=comm)
```
This way the system is only constructed on rank 0 (so we save memory), however the user
has to make sure that they use MPI correctly (e.g. call `solve` on all ranks to avoid a deadlock)
futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/17Plotting hoppings as arcs2019-02-09T22:19:56ZJoseph WestonPlotting hoppings as arcs Make an option for plotting hoppings as arcs, in order for overlapping
hoppings to be distinguishable. Also potentially add arrows to the hoppings. Make an option for plotting hoppings as arcs, in order for overlapping
hoppings to be distinguishable. Also potentially add arrows to the hoppings.future