dmcclean / igrf Goto Github PK

In discussion of #4, @bjornbm suggested switching to a sparse representation of the model coefficients:

However, and this should probably go in a separate issue, I'm thinking that perhaps the model should use [((Int, Int), (a,a))] or other representation of sparse matrix? Conceivably lower frequencies coefficients could be insignificant and omitted (=0) with high frequency coefficients significant. Think analogously to Fourier series and low-pass filtering, or just omitting coefficients below a certain threshold (significance).

I think that the entire "row" for a given degree may be necessary to make much sense, and so we might only want to be sparse in the first index? Except for so-called "zonal harmonics" where you only have one coefficient for each degree.

I'd like to see development of this be informed by an example application. Particularly because there are several flavors of spherical harmonics out there. The one we have now is the one the magnetics literature likes, but there are subtly different ones in use in other fields. In which of those fields are low-frequency terms sometimes negligible? Is there other generality we need first to reach those applications that might inform the design? etc.

Strangely, two years ago I did some preliminary work on exactly such an application (concerned only with high-frequency terms) but unfortunately I could never sell it to anyone. It was potentially cool though, if nobody has any actually useful proposals I might dust that off just because.

If we can extend the combine function to add together models with different reference radii then we can make a respectable VectorSpace instance.

I'm probably not using it right, but:

*IGRF> evaluateModel (fieldAtTime igrf11 0) 6371.2 (pi/2) 0
2.2596891744287066e7

versus the output from http://www.ngdc.noaa.gov/IAGA/vmod/igrf11.f where

2010.000 Lat   0.000 geocentric Long    0.000  6371.200 km apan
               D =   -6 deg   6 min    SV =       8 min/yr
               I =  -29 deg  13 min    SV =      -8 min/yr
               H =   27791 nT          SV =      -1 nT/yr
               X =   27633 nT          SV =       6 nT/yr
               Y =   -2953 nT          SV =      64 nT/yr
               Z =  -15545 nT          SV =     -86 nT/yr
               F =   31843 nT          SV =      41 nT/yr

where F = total intensity.

What am I doing wrong?

Evaluating the magnetic field at the (spherical, not magnetic) poles you NaNs.

To boil down the example, this happens even for the zero model

Data.VectorSpace Math.SphericalHarmonics IGRF> evaluateModelGradient zeroV 1 0 0
(-0.0,NaN,-0.0)
Data.VectorSpace Math.SphericalHarmonics IGRF> evaluateModelGradient zeroV 1 0.00001 0
(-0.0,-0.0,-0.0)
Data.VectorSpace Math.SphericalHarmonics IGRF> evaluateModelGradient zeroV 1 (pi) 0
(-0.0,NaN,-0.0)
Data.VectorSpace Math.SphericalHarmonics IGRF> evaluateModelGradient zeroV 1 (pi - 0.00
001) 0
(-0.0,-0.0,-0.0)

Of course, the derivative there in the North/South direction makes sense to not be defined, because which way is North is also not defined.

Keeping the NaNs probably makes more sense than fuzzing the inputs. If applications want to fuzz the inputs they can always do so themselves.

Is there any way to recover the value of the field expressed in the Cartesian coordinates "naturally" associated with these spherical coordinates? I believe the usual convention is that the z axis pierces the poles, the x axis pierces the equator at longitude/azimuth 0, and right-handed. Maybe if there is nothing more elegant, make a function with outputs in that frame that does fuzz the inputs?