Adding new kernel for boson
Closed this issue · 7 comments
The Lehmann representation of a bosonic correlation function:
∫ Kb(τ, ω) ρ(ω) dω
= ∫ exp(-ωτ)/(1-exp(-ωβ)) ρ(ω) dω,
where
ρ(ω) = (-1/π) Im G(ω+iδ).
Because Kb diverges at ω=0, we usually introduce a weight function.
For KBFlat, we use
∫ Kb(τ, ω) ρ(ω) dω
= ∫ ωexp(-ωτ)/(1-exp(-ωβ)) (ρ(ω)/ω) dω,
= ∫ KBFlat(τ, ω) (ρ(ω)/ω) dω.
In analytic continuation, this weight function ω becomes too large at high frequencies, leading to oscillations in reconstructed ρ(ω).
This can be solved by using another weight function:
∫ Kb(τ, ω) ρ(ω) dω
= ∫ ωexp(-ωτ)/(1-exp(-ωβ)) (ρ(ω)/ω) dω,
= ∫ KBFlatTanh(τ, ω) (ρ(ω)/tanh(βω)) dω,
where
KBFlatTanh(τ, ω) = KFFlat(τ, ω)
for 0 < τ < β.
This definition has been used in the Lattice QCD community (see H. B. Meyer (2007) and E. Itou et al. (2020)).
This weight function matches the old one up to a constant at low frequencies, but it does not diverge at high frequencies. More importantly, KBFlatTanh has the same dimension as KFFlat. Thus, the new definition is more natural, I think.
Following this, our C++ program SpMv2 and a new Python library spm_omega use the new one.
But, using KFFlat for constructing a bosonic basis looks confusing. How about introducing a new type KBFlatTanh? Better naming? I want to make KBFlatTanh a default choice but it may be too radical.
We could rename KernelFFlat to KernelFFlatBTanh? Or simply to LaplaceKernel (because it is essentially a Laplace transform), HilbertKernel (because of the connection to the Hilbert transform), LogisticKernel (because the logistic function appears in it)?
Which one is which? LogisticKernel = KernelFFlat, ...
I do not have strong preferences for naming. Whatever you like is fine!
We could introduce a new optional argument use_logistic_kernel to generate a basis with the new bosonic kernel.
We could use:
KernelFFlat -> LaplaceKernel
KernelBFlat -> RegularizedBoseKernel
We could also simply make the laplace/logistic kernel the default ... and have it override using the kernel= argument?
To just make sure, logistic kernel = new one with tanh?
Yes, precisely ... since it is a different package, we do not have to go out of our way to keep the old defaults, particularly if the new ideas are nicer. We do need to be careful with the sparse_ir.adapter module, this needs to be kept at the old kernel.
Agreed!