Giter Club home page Giter Club logo

Comments (15)

pablosanjose avatar pablosanjose commented on June 3, 2024

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 Hamiltonians and Couplings 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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

BacAmorim avatar BacAmorim commented on June 3, 2024

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 the selfenergy(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 region
  • UnboundedLeadsWithCuts, 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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

BacAmorim avatar BacAmorim commented on June 3, 2024

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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

BacAmorim avatar BacAmorim commented on June 3, 2024

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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

pablosanjose avatar pablosanjose commented on June 3, 2024

Related: pablosanjose/Elsa.jl#32
Speculation: could use NEP-PACK to compute the pseudospectrum of an EffectiveHamiltonian.

from quantica.jl.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

BacAmorim avatar BacAmorim commented on June 3, 2024

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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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.

pablosanjose avatar pablosanjose commented on June 3, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.