Comments (15)
Design of BlockHamiltonian
type
A possible design that covers all the above use cases is the following
First we need a Coupling
that can couple any pair of cells. This is an analogous situation to Hamiltonian
, which uses HamiltonianHarmonic
for this, but the latter only support cell distances. Instead we could do
struct Coupling{C<:CellCoupling}
cellcouplings::Vector{C}
end
struct CellCoupling{L,L´,M,A<:AbstractMatrix{M}}
src::SVector{L,Int}
dst::SVector{L´,Int}
matrix::A
end
where src
and dst
refer to cell indices in the two coupled Hamiltonians.
Then we need to pack all Hamiltonian
s and Coupling
s into a BlockHamiltonian
. We can do
struct BlockHamiltonian
blocks::Matrix
end
This type is intentionally not concrete. The eltype
of blocks
is in fact Union{Hamiltonian, Coupling}
. One could do a concrete version of this, such as
struct BlockHamiltonian{NN,T<:NTuple{NN,Union{Hamiltonian,Coupling}}}
blocks::T
end
with NN = N^2
(i.e. NN = length(matrix)
) and the tuple encoding all the blocks along columns of the block Hamiltonian matrix
. But it would probably be difficult to make its constructor type-stable, as the type of the tuple element h_ij
is different depending on i
and j
. I suspect leaving this as abstract, and then relying on function barriers would likely make the code both simple and performant, perhaps even reducing compilation time. We'll have to test and see.
from quantica.jl.
API
For problem (5) we could just keep using combine(hamiltonians...; coupling = model)
. To make the behavior clearly, I would suggest we rename combine
to merge
, however, which emphasizes that the output is still a Hamiltonian
.
For the rest we could use couple(hamiltonians...; coupling = model)
, where model
contains all possible couplings between pairs. We would have to restrict its use of the kwarg dn
(which by the way we should rename to something clearer, maybe dcell
). Hence dn
for all terms should be missing or we get an error in couple
. The coupling distance should simply be fixed by range
. Likewise, all terms should be hopping
(also in merge
).
We could also implement an indexing API for bh::BlockHamiltonian
, such as bh[i,j][dst, src][site2, site1]
to address the bloch h_ij
, at cells dst
, src
, and sites site2, site1
. This includes setindex!
methods for CellCoupling
. We should align the design of indexing of Hamiltonian
and BlockHamiltonian
to be as consistent as possible, although or course Hamiltonian
would only be able to address dcell = dst - src
, not (dst, src)
.
We will also need to extend the couple
API with a new kwarg, perhaps mincelldistance
or similar that ensures a minimal cell distance to be searched in order to build a Coupling
. This is required to make sure that 2 and 3 do become coupled cases like (2) above, despite doing so rather deep into the bulk of 2
mincelldistance
|
-------
11 | |
11 22222222222222⋱
11 3
3
3
3
⋱
from quantica.jl.
I am not sure that having a single BlockHamiltonian type would be the best approach. Instead of seeing all these cases as problems of coupled Hamiltonians, I think we should see them all as variations of case (1) [with the expection of case (5), which I agree should be kept as a seperate problem, with seperate methods], while allowing that for leads which are not necessarily semi-infinite 1D systems.
As a matter of fact, the Wide Band Limit approximation for leads falls outside the paradigm of scattering system as coupled Hamiltonians (in the Wide Band Limit, there is no Hamiltonian for the leads but only a self-energy).
I suggest we define an abstract type AbstractLead
, and a ScatteringSystem
(or some other better name) which is simply formed by a central 0D Hamiltonian + bunch of AbstractLeads. We would only demand that an AbstractLead encodes the information regarding the sites of the central Hamiltonian to which it couples, and to be able to return a self-energy and Gamma matrices, when necessary, by calling selfenergy(lead::AbstractLead)
and gamma(lead::AbstractLead)
. Then we could use multiple dispatch in order to use specialized algorithms for each of the cases you list.
We could define:
SemiInfiniteLead
type, for which the self-energies would be computed using the scattering states aproach.WideBandLimitLead
type, for the self-energy is simply a constant matrix, which can be explicitly stored in the struct.CoupledLeads
type, to account for case (2) and for which theselfenergy(lead::AbstractLead)
would deal with the coupling between the leads [I am not convinced there is any advantage in specializing for this case]UnboundedLeads
, which would simply be a periodic system + coupling to central regionUnboundedLeadsWithCuts
, which would be a periodic system + coupling to central region + rule to cut the periodic system (in order to form wedges, adding holes, ...)
In this maner, case (4) would be seen as a central 0D region (the part of the nanotube which opens as a funel) coupled to a SemiInfiniteLead (the nanotube) + a UnboundedLeadsWithCuts (the infinite graphene sheet with hole cut out).
Besides taking advantage of using multiple dispatch, I think this way of doing things would be future proof by being extensible. In case someone is interested in studying a problem with weird leads, which we have not considered, they can simply define their own concrete type of lead, with purpose built selfenergy
method.
from quantica.jl.
Nice, let me start discussing by parts. I actually think we agree on most points.
The most salient aspect of your proposal that is different from mine is your suggestion to keep the distinction between central hamiltonian and leads. Take for example a simple, 1D, SS' Josephson junction. There is no need for a central system. You become forced to build one to fit into the lead-central-lead mold. What is the advantage over simply allowing a direct hamiltonian-hamiltonian coupling?
A second part of your proposal is to associate self energies to leads. That is only possible with decoupled leads, I think. What you really want is to be able to first compute the Green function of all decoupled Hamiltonians, and then select one of them (say Hamiltonian h_n) and find the self energy created on it by all the rest when they become coupled. Hence, it is not so clear to me how to implement your CoupledLead
differently that in my proposal.
Another issue you bring up is the need for WideBandLimitLeads. Good point, I forgot about that. Could that not be just a special type of AbstractHamiltonian
possibility in blocks
?
Semibounded lattices are already supported in the code (its a Bravais property). In fact, any Hamiltonian is already unbounded (default) or semibounded along different axes. The idea is that the semibounded flag will be looked at when computing the decoupled Green function of a given Hamiltonian, and the method of images will be used if true.
I think your UnboundedLeadsWithCuts
is equivalent to WithVacancies{Hamiltonian}
So, can you come up with a compelling argument that keeping the type of MathQ design based on scattering system = central system - decoupled leads is a worthwhile restriction?
EDIT: also, your proposal seems to be against unifying all possibilities into a single BlockHamiltonian
type. Please do elaborate on the advantages, considering that multiple dispatch can still be implemented at the decoupled GreenFunction
level.
from quantica.jl.
To incorporate the WideBandLimit
case and the WithVacancies
cases, we can do
struct BlockHamiltonian{NN,T<:NTuple{NN,Union{AbstractHamiltonian,Coupling}}}
blocks::T
end
and then set up the AbstractHamiltonian
interface to support
greenfunction(h::AbstractHamiltonian, projector = I)
for the AbstractHamiltonian
you need.
For example with h::WideBandLimit <: AbstractHamiltonian
we (or the user) would define g = greenfunction(h::WideBandLimit, projector)
so that g(ω) = im * h.Gamma * I
, and let that feed into the selfenergy calculation for coupled systems.
(I'm working on another issue about the design of GreenFunction, coming soon)
from quantica.jl.
I will start with the Wide-Band Limit (WBL) case:
Indeed, in principle, I think it would be possible to consider a WBL self-energy as a subtype of AbstractHamiltonian
. Although it seems a bit weird to me to do so, since very little properties of an Hamiltonian remain true for a self-energy in the WBL. The WBL self-energy is anti-hermitian and there is no meaning in talking about its spectrum. Also, in the WBL we do not even have access to the green's function of the lead: the WBL approximation only describes the self-energy that is induced in the "central sample" (and therefore is an approximation to Σ(ω) = V*gLead(ω)*V
, which in the WBL is simply replaced by a constant matrix ΣWBL(ω) = -im*Γ
). In this case, as I see it, the only method that should be callable for a WBL self-energy is selfenergy
. Would it still make sense to consider WideBandLimit <: AbstractHamiltonian
?
Regarding the advantages of the separation of the central region:
Indeed, if we have an interface between two systems, there is no need to arbitraraty separate the system between leads and central region. The advantages of this separation appears in transport. When this separation is made, you now longer need to evalaute any Green's function explicitly. The evaluation of lead self-energies reduces to the problem of finding travelling states, and we never need to explicitly evaluate the Green's function of the central region: you only need to find how this Green's function acts on the incomming states (which is just a linear algebra problem). But, perhaps all of these things that be dispatched at a later point as you suggest. How are you thinking about dispatching for this particular case?
I think your UnboundedLeadsWithCuts is equivalent to WithVacancies{Hamiltonian}
One clarification: when you mention method of images, what to you mean exactly? Is this what allows you to see a semi-infinite chain as one infinite chain that you cut in half, and compute the boundary self-energy from the infinite chain Green's function? If that is the case, then indeed what I refered to as UnboundedLeadsWithCuts is just what you called WithVacancies{Hamiltonian}
from quantica.jl.
Regarding the WBL pseudo-Hamiltonian, it is its Green's function gLead(ω)
that is equal to gLead(ω) = iπρ₀
, independent of ω. That corresponds to the limit of essentially any Hamiltonian in the wide-band limit, in which ρ(ω) ≈ ρ₀. We would just need to dispatch g(ω) for g::GreenFunction{WideBandLimit}
About the central-lead structure, I wouldn't want to center the design of GreenFunction
to closely on transport setups. There are many, many problems that could be solved with GreenFunction that have nothing to do with Landauer, or leads. I thus fear such a choice could prove too constraining further down the road.
In any case, for Landauer-type problems, you say you don't need to build the Green function excplicitly. I would claim that any calculation that computes the scattering matrix in such a system can be cast as something revolving around the evaluation of a Green function. Of course, you don't need to evaluate it at all points in the central system. That is what the projector idea is for. Essentially you end up with a linear system of equations for G, projected onto a given subspace (typically the contacts), and its solution is much like solving a wavematching problem, complexity-wise. There are, by the way, quite a few approaches to do this that I would love to have your input about in the upcoming GreenFunction design issue. The solution method will indeed be cast as a multiple dispatch on a GreenFunctionSolver
By method of images, I mean that if you have a semi-infinite lattice, e.g. a quasi-1D lead, the Green function on the lead can be written like g(r, r') = g0(r - r') - g0(r + r'), where g0 is the Green function of the infinite system. That's in the continuum, with a trivial generalization to discrete lattices. In arbitrary dimension there is always just a finite number of such image terms, as long as you keep to the semibounded along different axes.
from quantica.jl.
Mmm, there is a problem, however, to fit a pseudoHamiltonian such as WideBandLimit into the mold of couple(hs...; coupling = model)
. model
is a hopping
, with a certain hoppingselector
... How is it supposed to build the Coupling
to the pseudoHamiltonian if the latter has no sites? Perhaps, instead of adding a WideBandLimit
as a block, we could make coupling
accept onsite
terms, that implement the constant self-energy on a set of sites specified by onsiteselector
. Just an idea.
from quantica.jl.
That is what the projector idea is for.
The solution method will indeed be cast as a multiple dispatch on a GreenFunctionSolver
Ok, I understand the idea.
Mmm, there is a problem, however, to fit a pseudoHamiltonian such as WideBandLimit into the mold of couple(hs...; coupling = model). model is a hopping, with a certain hoppingselector... How is it supposed to build the Coupling to the pseudoHamiltonian if the latter has no sites? Perhaps, instead of adding a WideBandLimit as a block, we could make coupling accept onsite terms, that implement the constant self-energy on a set of sites specified by onsiteselector. Just an idea.
Yes, that is the thing with the WBL (and for any self-energy really), all the details of the original Hamiltonian are washed away.
As an alternative for your suggestion, maybe the BlockHamiltonian could contain a union of Hamiltonians, Couplings and SelfEnergies? Other cases, besides the WBL, where specifying a self-energy directly might be useful, is for the cases when we actually know the self-energy analytical form (such as 1D chains or Bethe Lattices). In this situation, this quantities would be functions of energy, so again, they are not simple onsite terms.
from quantica.jl.
Excellent point. Yes, I'm beginning to see that making SelfEnergy
the fundamental type to build upon might be wiser than seeing self energies as simply an intermediate byproduct of a BlockHamiltonian
in our way to computing something else.
Maybe we need to sleep on it a bit to get closer to an optimal solution. But in any case, we will need to support the standard Landauer situation in particular, wherein the self-energy is computed from a bunch of Hamiltonians and their couplings. So BlockHamiltonian
will still need to exist in some form, even if its only goal is to compute a collection of self-energies to be added to a given Hamiltonian. Perhaps we want a new type of
struct EffectiveHamiltonian{H<:Hamiltonian,S<:SelfEnergy}
hamiltonian::H
selfenergies::Vector{S}
end
that is produced from a BlockHamiltonian
or a different source (including phenomenological or many-body models for the self energies), and from which to compute things like transport, density of states, etc...
from quantica.jl.
Related: pablosanjose/Elsa.jl#32
Speculation: could use NEP-PACK to compute the pseudospectrum of an EffectiveHamiltonian
.
from quantica.jl.
Hmm! Suppose we completely drop the BlockHamiltonian
idea and consider an API like the following instead
heff = hamiltonian(lattice, model) |> attach!(hlead1, coupling; solver = ...) |> attach!(hlead2, coupling; solver = ...)
where attach!(h::Hamiltonian, hlead1::Hamiltonian, coupling; solver = ...)
returns an EffectiveHamiltonian
as above with a single self energy in the selfenergies
vector, computed using a specific solver and the coupling::TightbindingModel
, and attach!(eh::EffectiveHamiltonian, hlead2::Hamiltonian, coupling; solver = ...)
simply adds another selfenergy to the selfenergies vector. This way we can easily attach independent leads efficiently. Adding a WBL selfenergy would be simply a matter of defining a push!(eh::EffectiveHamiltonian, s::SelfEnergy)
method.
Then, if we indeed need to address problem (2) of coupled leads, we would simply implement an attach!(eh::EffectiveHamiltonian, coupledleads::EffectiveHamiltonian, coupling)
that does the required math to build the relevant self-energy and add it to eh.
I think I like this approach. It is much closer to your original idea, separating central from leads. In this form, central is just the one EffectiveHamiltonian
you are interested in building, but without restrictions about dimensionality or origin of selfenergies. What do you think?
from quantica.jl.
I think there is some convergence going on and I like the new proposal, but a crossing might have occured. I do think you are correct in saying that the final design should allow for standard transport setup, while allowing for other cases. I think Green's functions are most useful for scattering problems, of which transport and few-impurity problems are particular cases.
So in this new proposal how would impurities be dealt with? The problem of adatoms attached to a periodic systems can be described in this new way: you consider the Hamiltonian of the isolated impurities to which you attach the periodic system. But what about disorder potentials (which do not enlarge the Hilbert space)?
Also, what about 2 semi-infinite systems connected? Would you consider one of the two as the "main hamiltonian" to which you attach one lead?
from quantica.jl.
Inpurities: just attach a 0D lead with the impurities. That should induce a real self-energy, save precisely at resonant energies (1/(ω-ϵ_imp + 0im)). Compute the scattering matrix in the presence of that self-energy.
Disorder potential: build a very large 0D parametric hamiltonian ph = parametric(h, onsite!((; seed = 1) = (Random.seed!(seed); randn())))
that takes as parameter the random seed for disorder. Then do KPM on ph(seed = n)
for various n
and average. When we have lazy Hamiltonians (#45) there will be another option, closer to what Kite does, that can implement KPM without building the large 0D hamiltonian in memory, but I doubt there will be a strong advantage in practice. Then again, you could use some theory of disorder, implement the disorder average as a many-body self-energy and do some diagramatics to approximate it as a single-particle self energy... Or use the replica trick. The main goal is to have Elsa.jl allow several approaches with maximum flexibility.
Two semibounded systems: choose one of them, introduce the other as a self-energy, and use Lippman-Schwinger to compute the scattering matrix in the presence of the self-energy. Just words at this stage, but I'm pretty confident it can be done (i.e. I've done it in MathQ). The question is whether we can write a generic approach to compute transport that applies to all cases: 0D central system with self-energies (where one would tend to use Caroli's formula) and finite-D lead with self-energy (where one uses Lippman-Shwinger smatrix formalism)
from quantica.jl.
This design issue is now mostly obsolete. We now have OpenHamiltonian which incorporates other systems as SelfEnergies, and can be converted to GreenFunctions, etc.
from quantica.jl.
Related Issues (20)
- Self-consistent mean fields HOT 5
- 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
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.