Dear Thomas,
yes, the tkwant version I am using is already doing the casting of the time-argument for any _LocalOperator. In that sense our two specialized operators are a priori time independent but will eventually be time dependent just as it is the case for the Current operator or Density operator, which also inherit from the _LocalOperator.
Concerning the general operator, it will for sure remain publicly available. How exactly will depend on the decision of the kwant core developers -- whatever will be the most convenient way.
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.