spm-lab / sparse-ir Goto Github PK

Not urgent.
Saving a basis (singular values and piecewise polynomials) to a HDF5 file.
This feature may be useful when performing diagrammatic calculations with varying temperatures.

At the same point, we may be able to support Fortran and C by writing a simple interface (evaluation basis functions from saved results).

I have noticed an incosistency in the input of eps for the holding class FiniteTempBasisSet. Different to IRbasis or FiniteTempBasis, it does not have eps=None as standard input. For ease of use this should probably be consistent.

On the same note, I noticed that eps is added as an attribute in FiniteTempBasisSet (line 53), but not in the original IRbasis/FiniteTempBasis instances. Would it not be more consistent to add it there instead or even pass it from the SVE decomposition (and then add eps as a property in the holding class)?
It has the advantage that eps could be saved in/reused from metadata of calculation files more easily. Then, eps should be saved after SVD, so that it can be looked up after not setting eps/using eps=None as an input.

I would have created a PR to fix the inconsistency in FiniteTempBasisSet, but I am not sure about your thoughts on the rest.

Just memo

W can use Eigen3 + QD, but we need to patch QD because

• QD does not have expm1.
• Their version of + has fairly large accuracy problems.

Just a memo.
It's better to define a minimum supported version of xprec and check the version of the installed one if any at runtime.
pip3 install -U irbasis3 won't update xprec automatically.

One thing that bugs me slightly as the 1.0 release is coming up is the PiecewiseLegendrePoly and PiecewiseLegendreFT classes.

If, at any point in the future, we want to switch to a different set of functions, for instance, if we manage to find something that is close in analytic structure to the IR functions, then we will have to increment the major version.

So, the question is whether we should introduce abstract TauFunction and MatsubaraFunction types that forms base types for PiecewiseLegendrePoly and PiecewiseLegendreFT, respectively, have the documentation/type hints refer to those types and then rename poly to _poly?

What do you think? Not hugely important, but maybe something to think about ...
@samuel3008 this of course would be something that would need mirroring in the SparseIR.jl repo...

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.