Normalization?

[dlfivefifty]

@jagot suggested Condon–Shortley:

If you choose Condon–Shortley (which is commonly used by physicists), you could employ https://github.com/Jutho/WignerSymbols.jl for exact angular integrals. This is what I use in https://juliaatoms.github.io/AngularMomentumAlgebra.jl/dev/.

@MikaelSlevinsky Any preference?

[MikaelSlevinsky]

I wouldn't touch spherical harmonics without (near) L² orthonormalization. Near being something like what they do in geodesy or magnetics https://en.wikipedia.org/wiki/Spherical_harmonics#Conventions.

Near orthonormalizations and phase conventions could be implemented as an afterthought. See also https://nschaeff.bitbucket.io/shtns/spec.html

[dlfivefifty]

The actual normalisation can be a user choice:

SphericalHarmonic() * Diagonal(...)

We can make the default orthonormal

[MikaelSlevinsky]

Quickly looking at https://juliaatoms.github.io/AngularMomentumAlgebra.jl/dev/definitions/#Spherical-harmonics-1, I think we largely agree: theta is co-latitude, L^2 orthonormalization.

[jagot]

I think a general library like SphericalHarmonics.jl should probably cater to different normalizations and phase relations. For me, it was very important that AngularMomentumAlgebra.jl is consistent in every possible choice of convention, since you otherwise can't trust relations. I therefore selected Varshalovich (1988) as the single source of truth. In quantum mechanics, Condon–Shortley is often used, because it gives real Clebsch–Gordan coefficients, as does the Fano–Racah convention (less often used, I think). Landau & Lifshitz instead uses complex CG coefficients, I forgot what they gain from that – maybe some formulas are simplified.

[dlfivefifty]

I can rename it SphericalHarmonicsQuasi.jl, I have no interest or time in making something encyclopedic

[jagot]

For sure, I would not suggest everything should fit in here, but it seemed both you and Mike agreed that various orthonormalizations were easy to bolt on, later.

I thought we both agreed we'd like to do away with the *Quasi.jl suffix 😛

[dlfivefifty]

Yes I just mean I'm not trying to be too ambitious right now. I'm just going to implement some basic functionality, e.g., solving Poisson .

I'm inclined to use the DLMF convention:

https://dlmf.nist.gov/14.30

Not sure what that corresponds to...

[jagot]

As long as the associate Legendre polynomial P includes (-1)^m, the so-called Condon--Shortley phase, it's the same as I am using.

[dlfivefifty]

Will follow Wikipedia as the default, added tests compared to https://en.wikipedia.org/wiki/Table_of_spherical_harmonics

Any feelings whether they should be defined only on the sphere or all of R^3? Off the sphere they would be the harmonic polynomials

r^m * Y_l^m(θ,φ)

[jagot]

The spherical harmonics are, as far I'm concerned, only defined on the sphere. The radial dimension is taken care of by other means, e.g. Laguerre polynomials for bound states of hydrogen or finite-difference/-elements in numerical codes.

[dlfivefifty]

It is often natural to incorporate the r^m in the spherical harmonic part: that is, if you have something like r^m * exp(-r) * L^(m)(r^2)* Y_l^m(θ,φ) this is replaced by exp(-r) * L^(m)(r^2) * Y_l^m(x,y,z).

Both can (and will) be supported so it really is just an implementation detail. That is, if we make them by default defined on R^3 one can still use spherical coordinates but also euclidean:

S = SphericalHarmonic()
S[SphericalCoordinate(θ,φ), Block(l)[m]]
S[SVector(0.1,0.2,0.3),Block(l)[m]]

If you wish the latter to give a bounds error you can do

S = SphericalHarmonic()[UnitSphere(),:]

But I'll mull it over a bit more...

[MikaelSlevinsky]

I think the (regular) solid spherical harmonics are r^l * Y_l^m(θ,φ). I think they'd be great to have around. Also, there are irregular harmonics r^{-l+1} * Y_l^m(θ,φ) that are square integrable in the exterior of the unit solid sphere (ball). These would be the analogues of Hardy{true/false} in ApproxFun.

[MikaelSlevinsky]

Transforms/plotting are fast on concentric spherical shells

[dlfivefifty]

Would BallHarmonic be an appropriate name?

[MikaelSlevinsky]

Yeah that or SolidSphericalHarmonics{true/false}(). I'll live with the de facto name

[dlfivefifty]

we would need to change the name of the package for the type to be called SphericalHarmonics. I'm not opposed to that.

[MikaelSlevinsky]

Sorry, I guess the quasi-space doesn't have to be pluralized? Since we don't have, e.g. LegendrePolynomials.

[dlfivefifty]

Some more thought needs to be done here. Actually, it's the same issues with Taylor series (2D Spherical harmonics). Is the canonical axes(Taylor(),1) (i.e., the domain of definition) equal to

1. UnitCircle{ComplexF64}()
2. UnitDisk{ComplexF64}()
3. C (that is, EuclideanSpace(Complex64))

Each has valid a valid usage...