Comments (3)
I think it is a good idea to add a field hermitian
to a Hamiltonian declaring if the Hamiltonian should be Hermitian or not. Then this info can be passed to a Diagonalized algorithm and each algorithm will do what it wants with that info.
Also, I think it would be useful to add a method to ishermitian
, which allows the user to test whether the Hamiltonian they have built actually is Hermitian or not and whether this contradicts the declared field.
Finally, I think the forcing of setindex! to preserve hermicity (by automatically adding a hopping B=>A, if we set a A=>B hopping), should be an option forcehermitian
(which we might default to true if hermitian=true).
My reason to propose this as an optition is the output of Wannier calculation. The hoppings are returned without any concern of hermiticity. If we always force hermiticity in setindex!
will add the same hopping twice, which would be a waist of time.
Just my €0.02.
from quantica.jl.
I think I agree. The main reason of the Hermitian wrapper is to be able to have type-stable diagonalize methods, that return either real or complex eigenvalues. The approach in pablosanjose/Elsa.jl#37 addresses this issue, and I think the decision there is solid. The ishermitian
field would then not be used to determine the type of eigenvalues (they would always be of the same type of momenta), although it could be used to set the imaginary part to zero in the complex case.
The problem of having a field that promises hermiticity is that it could lie, unless we force the API everywhere to respect this. If we use a setindex! that does not forcehermitian
on a Hamiltonian with ishermitian == true
, should we update ishermitian
to false
? What if we then add the conjugate element to restore hermiticity?
One might think the solution is to set ishermitian
to false, unless the conjugate of the element being set is present, in which case we set it to true. But that doesn't work, because if it is present we cannot be sure the entire matrix is hermitian.
I suspect the only way to solve this is to make the ishermitian
property inmutable, and make setindex!
respect it. In the Wannier case we can just set forcehermitian = false
when building the original Hamiltonian, if we want to set all elements independently.
Finally, another reason to not encode hermiticity at the type level, and keep it as a Boolean struct field as you say, is that the package is already becoming slightly parametric-heavy. This is still not a problem for compilation time, but in the future I'd like to look into ways of simplifying the type parametrizations if possible.
from quantica.jl.
I'm less inclined since #38 to bake in privileged behavior for Hermitian matrices. As the package progresses it will become more and more common, I think, to consider open systems with non-Hermitian self-energies, or other uses beyond the strict tight-binding mindset. I'm currently working in a problem with a non-symmetric real "Hamiltonian" (in the sense of an inverse equation of motion Green's function) that benefits from all the Quantica machinery (including bandstructure calculation) without being Hermitian. I suggest we close this for the moment until we find a real need to impose/check hermiticity in a non-standard way. Otherwise, we should simply follow the Julia approach and extend the API with wrapped Hermitian(Hamiltonian)
from quantica.jl.
Related Issues (20)
- Taking blocks seriously HOT 5
- Multiorbital systems: replace `SMatrixView` with a `Union` over different `SMatrix` eltypes HOT 1
- Provide wrappers to matrices / vectors to indicate parent Hamiltonian an allow use of siteselector HOT 8
- Allow construction of Hamiltonian by providing Harmonics HOT 2
- Segfault (use-after-free?) due to interaction between FunctionWrappers and Julia 1.10 HOT 1
- GreenFunction of AbstractHamiltonian{Float32} fails
- Add support for (energy dependent) unbounded self-energies HOT 1
- Add support for `qplot(h::OpenHamiltonian)`
- Parametric models don't support parameters without default values HOT 1
- Schur leads with additional self-energies are broken
- Issue with boundary construction in `GS.Bands`
- `GS.Bands` and Divide by zero
- Taking Operators seriously HOT 2
- Make `inspector = true` the default
- Broken closure in GreenFunction HOT 1
- Subtle aliasing issue in Schur slicer
- Allow for combination of parametric hamiltonian HOT 1
- Add selector indexing of `AbstractHamiltonian`s
- Tooltips in `plotlattice` of heterogenous multiorbital systems should show non-square blocks
- Spectrum not working for OpenHamiltonian HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from quantica.jl.