kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/-/issues2020-10-23T09:41:18Zhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/394Factor out `kwant.kpm`2020-10-23T09:41:18ZDániel VarjasFactor out `kwant.kpm`Anton suggested that it would be better in the long term to separate `kwant.kpm` in its own package, so other projects that rely on a general KPM implementation don't need to import all of kwant. This would also make it more transparent ...Anton suggested that it would be better in the long term to separate `kwant.kpm` in its own package, so other projects that rely on a general KPM implementation don't need to import all of kwant. This would also make it more transparent to add improvements to the KPM implementation that are independent of kwant (for example I'm working on implementing KPM in a non-orthogonal basis now, something that kwant doesn't support yet).
What do you think @anton-akhmerov @cwg @pablopiskunow ?https://gitlab.kwant-project.org/kwant/kwant/-/issues/186New Kwant Logo2020-10-22T09:03:19ZGeorge Datserisdatseris.george@gmail.comNew Kwant LogoDear All,
after personal communication with @cwg , I am very honored to have been invited to perform such a task (to make a new logo for kwant). Kwant is an amazing software and I have big respect for all the developers here, therefore ...Dear All,
after personal communication with @cwg , I am very honored to have been invited to perform such a task (to make a new logo for kwant). Kwant is an amazing software and I have big respect for all the developers here, therefore I am more than happy to contribute in any manner.
Before I begin let me say as clearly as possible that my time is limited at the moment, therefore results may take a *seriously long time*!
Now, we can get into business. There are some important factors that you should vote/participate/decide before I start making template ideas.
### Font
The font used for the logo is in my opinion the most crucial part. Besides aesthetic purposes, there are also licensing issues, as the font used must be accessible from kwant (and maybe even be part of the source code?). Below it will become apparent why.
I have decided to *not* choose a font myself, and instead first invite you to share with me fonts that kwant has direct access, and they are licensed in such a way that we can use them. I must admit I have 0 knowledge of licensing and I do not want to make any wrong move. When I create digital paintings on my free time, I just download fonts from `dafont.com`, assuming that they are all free and can be used for any (commercial or not) purpose. I haven't really checked though.
Share as many fonts as you like, I don't have a problem to go through even 100 fonts!
### Color combinations
Let me know whether there are some specific colors, or color combinations you feel like the new logo should have.
These can be inspired either by personal preference or by a deep internal story of kwant. Having something like the latter would be truly inspiring, regardless if the users can give any importance to the colors or not.
### On the current logo
The old font is a bit
> dry
and both me and @cwg agree on this fact.
However, after I learned it is produced using kwant, I can safely say that this is *super* awesome.
I really want the new logo to be in the same spirit: some base generated by kwant, with some artistic finishing touches. The plan is that from the new logo it is clear that it has been produced using kwant.
From the current logo is of course obvious that it ties to inspire something like some DOS / WF amplitude. What is not immediately obvious (at least for e.g. myself) is that it is a kwant script! I want to make this a bit more obvious with the new logo.
### Your suggestions
**Please feel more than welcomed to give suggestions, ideas, things that you would like to see or things that you believe *must* be part of the new logo**.
I think it is best if we all write suggestions/ideas in this issue. If you need to send me files (containing e.g. fonts), you can use my email `george.datseris@ds.mpg.de`.
### Other logos I've designed
I have designed 2 logos for 2 libraries I have developed (for Julia), with results:
https://juliadynamics.github.io/DynamicalBilliards.jl/latest/
https://juliadynamics.github.io/DynamicalSystems.jl/latest/
In both libraries the logo is also an output of a library script, in part only of course.https://gitlab.kwant-project.org/kwant/kwant/-/issues/104include models library into continuum2019-10-21T08:41:27ZRafal Skolasinskiinclude models library into continuumI believe it is a good idea to provide predefined ``models`` in ``continuum`` that can be directly used with ``discretizer``.
I believe this issue was discussed some time ago.
I can code them in if someone will help me to compose list ...I believe it is a good idea to provide predefined ``models`` in ``continuum`` that can be directly used with ``discretizer``.
I believe this issue was discussed some time ago.
I can code them in if someone will help me to compose list of them with references.
---
models to include:
1. 8 band k.p
2. BHZ model for QSH
3. BdG for SChttps://gitlab.kwant-project.org/kwant/kwant/-/issues/34Clarify docstring of kwant.physics.StabilizedModes2020-10-22T09:10:26ZChristoph GrothClarify docstring of kwant.physics.StabilizedModesThe second paragraph needs to be expanded and reformulated to clearly specify what the various attributes contain.The second paragraph needs to be expanded and reformulated to clearly specify what the various attributes contain.futurehttps://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/377Kwant does not release the GIL when calling Mumps2020-05-07T15:30:45ZJoseph WestonKwant does not release the GIL when calling MumpsTitle is pretty self-explanatory.
The fix should just be applying [`with nogil`](https://cython.readthedocs.io/en/latest/src/userguide/external_C_code.html#nogil) to [this line](https://gitlab.kwant-project.org/kwant/kwant/-/blob/master...Title is pretty self-explanatory.
The fix should just be applying [`with nogil`](https://cython.readthedocs.io/en/latest/src/userguide/external_C_code.html#nogil) to [this line](https://gitlab.kwant-project.org/kwant/kwant/-/blob/master/kwant/linalg/_mumps.pyx#L151).
Only thing to watch out for is if this gives degraded performance on very small systems.https://gitlab.kwant-project.org/kwant/kwant/-/issues/374The 'projectors' of a 'kwant.physics.DiscreteSymmetry' are not actually proje...2020-03-30T20:34:51ZJoseph WestonThe 'projectors' of a 'kwant.physics.DiscreteSymmetry' are not actually projectors`kwant.physics.DiscreteSymmetry` [has as a `projectors` property](https://gitlab.kwant-project.org/kwant/kwant/-/blob/master/kwant/physics/symmetry.py#L44), however the data stored here is not actually a projector.
The *actual* projecto...`kwant.physics.DiscreteSymmetry` [has as a `projectors` property](https://gitlab.kwant-project.org/kwant/kwant/-/blob/master/kwant/physics/symmetry.py#L44), however the data stored here is not actually a projector.
The *actual* projectors are constructed in the `validate` method ([see here](https://gitlab.kwant-project.org/kwant/kwant/-/blob/master/kwant/physics/symmetry.py#L201)).
See [here in the Builder](https://gitlab.kwant-project.org/kwant/kwant/-/blob/master/kwant/builder.py#L1811) where we construct "projectors" by selecting columns from the matrix of eigenvectors.
Clearly a true projector would be those matrices multiplied by their conjugate transposes.
IMO this is just an error in naming. Instead of `projectors` these things should be called `subspaces`. They are matrices that each have the following properties:
+ $`M`$ is a matrix whos columns span a given subspace $`V`$
+ $`M M^\dagger`$ is a projector onto $`V`$
Additionally the set of all projectors has the property that it is a partition of unity: $`\sum_i M_i M_i^\dagger = 1`$
It's fine that we store $`M`$ rather than $`M M^\dagger`$, but we should at least name them correctly.https://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....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/330be more systematic about use of random numbers within the tests2024-01-09T20:52:24ZJoseph Westonbe more systematic about use of random numbers within the testsKwant's test suite has flaky test failures. I do not believe that these failures are "bad" (i.e. they do not correspond to bugs in kwant) but they are not reproducible. I believe that this is because some of the tests rely on numpy's RNG...Kwant's test suite has flaky test failures. I do not believe that these failures are "bad" (i.e. they do not correspond to bugs in kwant) but they are not reproducible. I believe that this is because some of the tests rely on numpy's RNG, and we do not set the seed in a consistent way.
I know for a fact that some of the tests in `kwant.tests.test_qsymm` directly use numpy RNG, but even if other tests do not explicitly use it, the numpy RNG is sometimes used inconspicuously (e.g. during sparse diagonalization to choose the initial vector).
My proposal is to simply enable [pytest-randomly](https://pypi.org/project/pytest-randomly/) in CI, so that at least the CI tests are reproducible.
If we also want people to be able to run the tests in a reproducible way on their own computers then we should also make pytest-randomly a testing dependencyhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/280`plotter.interpolate_current` result depends significantly on CPU architecture2019-05-24T13:30:45ZChristoph Groth`plotter.interpolate_current` result depends significantly on CPU architectureI noticed that the test `kwant/tests/test_plotter.py::test_current_interpolation` in c7a135331090 fails on i386 while it passes on amd64. On both architectures, the environment is an up-to-date Debian testing, so that the software envir...I noticed that the test `kwant/tests/test_plotter.py::test_current_interpolation` in c7a135331090 fails on i386 while it passes on amd64. On both architectures, the environment is an up-to-date Debian testing, so that the software environment should be identical.
I narrowed down the problem to the following script. It calls `plotter.interpolate_current` with the same hard-coded data, but the result is different.
[test.py](/uploads/4af133fecb023a8cdf059556f84b6970/test.py)
I also attach a script that contains the output (`j0[y_axis]`) from both architectures and produces the following plot.
[plot.py](/uploads/bd7a0d4a273e14ca6bc1527082c900e7/plot.py)
![plot](/uploads/a625c96fbf448ebf686902934f48b39e/plot.png)
As one can see, the results on both architectures are similar, but vastly bigger than what seems acceptable due to differences between the architectures.
Once this bug is fixed, the original test should be reviewed. Check out the history to see how I dealed with the failing test for 1.4.0.
@jbweston, you know this code best, can you have a look?https://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/227MUMPS solver does not detect singular linear systems2018-09-14T13:05:00ZBenoit RossignolMUMPS solver does not detect singular linear systemsFor some system Mumps do not detect the singular matrix leading to incoherent results.
The system:
```
import kwant
R = 8
L = 1
M = int(0.8*R)
def region(x, y):
return (1.6*x)**2 + (y)**2 < R**2
lat = kwant.lattice.square(norbs=1)
...For some system Mumps do not detect the singular matrix leading to incoherent results.
The system:
```
import kwant
R = 8
L = 1
M = int(0.8*R)
def region(x, y):
return (1.6*x)**2 + (y)**2 < R**2
lat = kwant.lattice.square(norbs=1)
sys = kwant.Builder()
for x in range(-R, R):
for y in range(-R, R + 1):
if region(x, y):
sys[lat(x, y)] = 4
lead_left = kwant.Builder(kwant.TranslationalSymmetry((-1, 0)))
for y in range(0, 2*L + 1):
lead_left[lat(0, y)] = 4
lead_left[lat.neighbors()] = -1
lead_right = kwant.Builder(kwant.TranslationalSymmetry((1, 0)))
for y in range(-L - L // 2, L - L // 2 + 1):
lead_right[lat(0, y)] = 4
lead_right[lat.neighbors()] = -1
sys[lat.neighbors()] = -1
sys.attach_lead(lead_left)
sys.attach_lead(lead_right)
sys = sys.finalized()
```
The incoherent results are given by:
```
for i in range(20):
print(kwant.smatrix(sys, 4).transmission(0, 1))
```
Give each time different values between 0 and 35. The energy (4) is not a physically particular value, no band opening, closing or crossing.
Some beginning of answer: the linear system solve by mumps (ax=b) is singular for this particular value of energy (4) but the singularity is not detected.
```
import numpy
import scipy.sparse
ls = kwant.wave_function(sys, 4)
fh = ls.factorized_h
a = scipy.sparse.csr_matrix((fh.data, (fh.row-1, fh.col-1)))
b = ls.rhs[0]
print(numpy.linalg.det(a.todense()))
```
det(a) = 0, the matrix is indeed singular.https://gitlab.kwant-project.org/kwant/kwant/-/issues/154Improve documentation of DiscreteSymmetry2020-10-22T09:06:59ZChristoph GrothImprove documentation of DiscreteSymmetryI have the impression that the documentation of `kwant.physics.DiscreteSymmetry` could be improved.
Is using the method `validate` supposed to be the only documented way to use `DiscreteSymmetry` instances? I suppose not, because it's ...I have the impression that the documentation of `kwant.physics.DiscreteSymmetry` could be improved.
Is using the method `validate` supposed to be the only documented way to use `DiscreteSymmetry` instances? I suppose not, because it's used differently in `kwant.physics.leads`. Then, the four attributes should be documented.
What about `__getitem__`. It seems to me that this has been added so that one can write:
`projectors, time_reversal, particle_hole, chiral = discrete_symmetry`. Is this really useful enough to jusitfy that usage? If yes, I think that a cleaner way would be to derive `DiscreteSymmetry` from `namedtuple`.
A somewhat related question: I note that the code in `leads.py` gets the four matrices and then performs many transformations on them. Wouldn't it be possible to abstract some (or most) of this into generally useful methods of `DiscreteSymmetry`?futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/134continuum: substituting pauli matrices doesn't work inside kron2019-02-09T22:54:27ZRafal Skolasinskicontinuum: substituting pauli matrices doesn't work inside kronFor example this work
```
kwant.continuum.sympify('tau_x', locals={'tau_x': 'sigma_x'})
```
but this throws an exception:
```
>>> kwant.continuum.sympify('kron(tau_x, sigma_y)', locals={'tau_x': 'sigma_x'})
AttributeError: Immut...For example this work
```
kwant.continuum.sympify('tau_x', locals={'tau_x': 'sigma_x'})
```
but this throws an exception:
```
>>> kwant.continuum.sympify('kron(tau_x, sigma_y)', locals={'tau_x': 'sigma_x'})
AttributeError: ImmutableMatrix has no attribute args_cnc.
```https://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/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/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/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'*
```