Bug #1127

sph2grd

Added by Mark about 4 years ago. Updated 6 months ago.

Status:ClosedStart date:2017-07-06
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:Candidate for next bugfix release
Affected version:6.x-svn Platform:Linux

Description

Running gmt 5.4.0 on ubuntu 16.04.

I'm generating grids with sph2grd, for example with L=10, M=5, C=1, S=0. When setting the normalistaion flag to -Ng, I get grids who's inner products sum to 4*pi. However, when the flag is -Nm, they appear to sum to 0.5 rather than 1.

History

#1 Updated by Paul about 4 years ago

  • Status changed from New to Feedback
  • Target version set to Candidate for next bugfix release

Would you mind showing how you computed the 0.5 so I can make a test script for this. I am looking at the code and find
if (ortho)
plm[mm] = pmm * 0.5 / d_sqrt(M_PI);

so that 0.5 is suspicious in light of your post. But I'd like to verify first.

#2 Updated by Mark about 4 years ago

res="1" # deg - resolution of SH grid
pi="3.141592"

echo "Integrated Ylm**2 volume = "$(gmt grd2xyz sh.grd | awk 'BEGIN {sum=0} {sum+=(sin((90-$2)*'$pi'/180)*'$res'*'$res'*('$pi'/180)*('$pi'/180)*($3^2))} END {printf "%.6f\n", sum}')

#3 Updated by Remko about 4 years ago

Indeed the factor "0.5" should be "1.0". Fixed now in both trunk and branch.

#4 Updated by Remko about 4 years ago

  • Status changed from Feedback to Resolved

#5 Updated by Paul about 4 years ago

  • Status changed from Resolved to Closed

Closed as fixed.

#6 Updated by Mark 6 months ago

Sorry - not sure if this is still the correct place to report bugs... But I noticed that in GMT 6.1.1, this issue with sph2grd that I reported a few years ago has returned. Cheers

#7 Updated by Paul 6 months ago

  • Affected version changed from 5.x-svn to 6.x-svn

This is definitibvely not the place to report anything anymore - please use www.generic-mapping-tools.org for a portal to all things GMT, including the GitHub site where bugs and issues can be reported.

Looking at the code there are in fact two places where the plm[mm] = pmm * 0.5 / d_sqrt(M_PI);

type expressions appear, and it looks like Remko only fixed one as there is another where the 0.5 still lives. I will fix that in master now. You will need to build and test to be sure of send me a simple script that I can use to verify the result.

Also available in: Atom PDF