GenericMappingTools / GenericMappingTools/gmt
Normalization issues with sph2grd
- Dominant language
- C
- Stars
- 979
- Forks
- 414
- Avg merge
- 17h 26m
- Merged PRs (30d)
- 54
Description
**Description of the problem**
`sph2grd` does not appear to distinguish between Schmidt (`-Ns`) and 4pi normalizations (`-Ng`). It treats them both as `-Ng`, which leaves `-Ns` too large by a factor of $\sqrt{k(2l+1)}$ (Eqn. 10 in Holmes & Featherstone, 2002). I've attached a script which computes both and maps the difference using `grdmath`. I also have a fortran code which will downward continue an SH model to the CMB, where I implemented the changes that I think fix the problem. The results are all stored in the maps directory.
Inside this zip is everything you would need to produce these results for yourself. The results are pasted in this report though, so you don't need to run anything.
[sphNormTest.zip](https://github.com/GenericMappingTools/gmt/files/9428728/sphNormTest.zip)
**Error**
No error msg produced by this but I traced the error back to a few sources.
In sph2grd.c:
Within the `struct N`, there is never any explicit use of the attribute `N.mode`. The only use I found is in specifying `bool ortho` on L360. As a result, when `gmt_plm_bar_all()` is called on L428, it does not carry along `N.mode`, only `ortho`.
In gmt_stat.c:
The function itself (L1098) could be modified to take another boolean input which specifies whether Plm are to be semi-normalized (schmidt) or fully normalized (4pi). For example,
At 1098:
`void gmt_plm_bar_all (struct GMT_CTRL *GMT, int lmax, double x, bool ortho, bool semi, double *plm)`
At 1137:
`bool csphase = false, semi;`
At 1195:
` r = (2*l+1.0) / (l+m) / (l-m);
if (semi) r = 1.0 / (l+m) / (l-m);
`
**Actual outcome**
[incorrectCMB.pdf](https://github.com/GenericMappingTools/gmt/files/9428743/incorrectCMB.pdf)
[incorrectSurface.pdf](https://github.com/GenericMappingTools/gmt/files/9428744/incorrectSurface.pdf)
**Expected outcome**
[correctCMB.pdf](https://github.com/GenericMappingTools/gmt/files/9428742/correctCMB.pdf)
[correctSurface.pdf](https://github.com/GenericMappingTools/gmt/files/9428747/correctSurface.pdf)
The colorscales are the same at each respective radius. On the CMB, you can see the results differ significantly. The effect on the field shape is more noticeable on the surface
**System information**
* Operating system: Mac OS
* GMT version (`gmt --version`): 6.4.0
Contributor guide
Assessment
This issue has not been assessed yet.