Dear Thomas, dear Christoph,
just a quick update on the general Operator. Our PhD student Adel Kara Slimane had a nice idea for restructuring the code and thus enhancing its speed. Roughly speeking, we now strictly separate the path finding and the matrix products between operators and wave functions, which makes the code easier to read and also enhances the performance. Compared to the kwant-built-in operators, we get with the same system using the general operator the following speed for calls (=calculating matrix elements):
- Density: genOp roughly 1.5 times slower than kwant.operator.Density
- Current: genOp as fast as kwant.operator.Current
- Souce: genOp as fast as kwant.operator.Source (or maybe 1.05 times slower)
The difference between Density and Current can be explained by the fact that most of the calculation time is spent in creating the BlockSparseMatrices. Since for the Density no BlockSparseMatrix has to be created (in most cases), it is much faster (~100 times) than the Current. Due to our generalization a few additional steps are done which are not needed in the specialized case, which is why we do not obtain the same speed on the level of the density. However, as soon as BlockSparseMatrices are created (Current, Source) its creation outweighs these additional steps, which are present because of the generalization.
The initialization of those Operators is also comparable but anyway rather unimportant since it has to be done only a single time, while the operators have to be called for each energy and each mode (each scattering state).
For the moment, I think nothing will change on our plan: merging the specialized energy/heat current operators with tkwant. However, it is nice to know that there is in principle also the generalization of the operator module if ever needed, which is as (almost) as efficient as the specialized ones.
The new code and some plots for efficiencies can be found on my github repository:
https://github.com/PhiReck/generalOperator
The system for testing the efficiency is a square lattice with nearest neighbor hoppings. Both, width and length are changed when changing the system size. The operator matrix elements are calculated for each hopping/site in the system.
Best regards,
Phillipp
________________________________
Von: Thomas Kloss [kloss@itp.uni-frankfurt.de]
Gesendet: Montag, 25. Februar 2019 15:57
An: RECK Phillipp
Cc: kwant-discuss@kwant-project.org; GROTH Christoph
Betreff: Re: [Kwant] Heat and energy currents using tkwant
Dear Phillipp,
I also agree that one should add only the two specialized operators to tkwant.
But I have another question about your implementation of the two specialized operators:
To use the kwant operators in tkwant, we cast the
time argument in the calling signature of the operator as the first element of
the additional non-keyword arguments. However, this only happens when the operator
is of type kwant.operator._LocalOperator. It seems to me that an instance of your
CurrentWithArbitHop class is a priori time independent, but will eventually be
time dependent similar as its parent class kwant.operator._LocalOperator?
I ask this just to make sure that the tkwant version you are currently using
is doing already the above mentioned argument casting and to avoid this happening twice at the end.
As for the generalOperator module, I still think this is a neat feature
and might be useful when dealing with more complicated objects such as e.g. higher order correlation functions.
While I agree that two parent classes in kwant, _localOperator and generalOperator
could lead to confusions, there may be another alternative.
So this is more a point to discuss with the core developers of kwant,
but isn't there a way to release the generalOperator as as some kind add-on module?
Best, Thomas
On Friday, February 22, 2019 17:57 CET, Christoph Groth
Concerning the question of whether they should be integrated to kwant or to tkwant: I guess I agree that a good place for the specialized currents is tkwant whereas the generalOperator would fit better into kwant. The only problem and/or inconsistency, that I see, is the fact that there would be then two different parent classes for operators in kwant, the _localOperator and the generalOperator. The former is faster since specialized, the latter simplifies the generation of new operators since there is no need for an _operate method in each new operator, as opposed to the _localOperator.
If I understand correctly, there is currently no use case for the general operators. If this is indeed the case, perhaps we should rather not add this code at all, and only add the specialized operators to tkwant.