... | ... | @@ -245,13 +245,15 @@ conform to this interface. Solvers implemented in C may rely on this interface. |
|
|
There are two possible reasons why having a C interface to Kwant systems
|
|
|
is important:
|
|
|
|
|
|
+ Someone may wish to implement a system for performance reasons
|
|
|
+ Someone may wish to implement a low-level system directly in C for
|
|
|
performance reasons
|
|
|
+ Someone may wish to interface a Kwant system with an external solver
|
|
|
that provides some functionality that is *not* provided by Kwant
|
|
|
(e.g. RGF is not currently implemented in Kwant).
|
|
|
|
|
|
It may be argued that the first reason is not so relevant now that the
|
|
|
low-level format supports vectorized evaluation of the Hamiltonian.
|
|
|
low-level format supports vectorized evaluation of the Hamiltonian,
|
|
|
which the `kwant.builder.System` implementation will do.
|
|
|
A performance-conscious user who has pinpointed the evaluation of the
|
|
|
Hamiltonian as a bottleneck may just vectorize their value functions.
|
|
|
In this way there is only 1 Python function call for each value
|
... | ... | @@ -371,7 +373,8 @@ struct Block_t { |
|
|
This would be more transparent, and might give us some performance
|
|
|
gain from accessing aligned memory (if we use 32-bit integer
|
|
|
types), although we are certainly not at this level of micro-optimization
|
|
|
yet.
|
|
|
yet. In addition, we would have to make sure that this is compatible
|
|
|
with the Python interface.
|
|
|
|
|
|
##### Symmetries should have an `act` method
|
|
|
Instead of explicitly constructing the `U(N)` representation we should probably
|
... | ... | |