Recalculation of azimuth in ROPP

[Ian Culverwell]

Stig Syndergaard (DMI) questions the definition of azimuth in tangent_point.f90 and occ_point.f90:

> Hi Ian,
> 
> I'm back to some old issue: the tangent_point.f90 and 
> occ_point.f90 routines and their determination of the azimuth angle.
> 
> When I did the merge of ROPP 6.1 here at DMI some weeks ago, 
> I kept the changes that we have in our dmi_trunk ('DMI ROPP').
> 
> https://trac.romsaf.org/ropp/changeset/3645/ropp_src/branches/
> dev/Share/dmi_trunk_6.1/ropp_utils/coordinates/tangent_point.f90
> 
> https://trac.romsaf.org/ropp/changeset/3645/ropp_src/branches/
> dev/Share/dmi_trunk_6.1/ropp_utils/coordinates/occ_point.f90
> 
> I've attached a text file with the output of test runs 
> comparing the azimuth between different algorithms: GPAC vs 
> ROPP 6.1, and GPAC vs 'DMI ROPP'. GPAC is our operational algorithm.
> 
> I used samples of GNSS and LEO orbits from four occ files 
> (with the azimuth in each of the four quadrants) and wrote 
> out lat, lon, azimuth_gpac, azimuth_ropp for each test. As 
> you see there is a 180 deg flip between GPAC and ROPP 6.1. If 
> I do the same with GPAC vs 'DMI_ROPP' 
> they match nicely (see lower down in txt file). I believe 
> GPAC and 'DMI ROPP' are consistent with the definition of the 
> azimuth in the ROPP documentation (angle between line from 
> GNSS toward LEO compared to line straight north). This is 
> also what EUMETSAT uses. So I think it would be good if we 
> could fix this in the next ROPP release.
> 
> I also did four tests with the tangent point on each of the 
> poles and the GNSS-LEO line going straight north or straight 
> south (also in txt file). Surely, it can be argued what the 
> azimuth should be at the poles, it's basically undefined 
> (that is a flaw with the way of definition ... 
> azimuth could be defined in an alternative way, which would 
> allow reconstruction/knowledge of propagation direction also 
> at the poles, but that's for another time), but a problem 
> also appears for GNSS-LEO lines going straight south. It's 
> related to the vector_angle subroutine, which does not give 
> the correct angle if the angle is precisely 180, unless an 
> axis of rotation is provided as the third argument (as in the 
> code change I suggested). The problem will probably never 
> appear in practice, but we might as well have it correct in 
> all cases to be on the safe side.
> 
> I didn't open a ticket on this, but I can do that if you want me to.
> 
> Kind regards,
> -Stig
> 

I also did some simple offline tests in simple geometry (TP at lat= lon=0, code in ~idculv/Fortran/Azimuth):

 *** LEO due west of GNS ***
 azimuth_ropp =    90.0000000000000     
 azimuth_gpac =    270.000000000000     

 *** LEO due east of GNS ***
 azimuth_ropp =    270.000000000000     
 azimuth_gpac =    90.0000000000000     

 *** LEO due north of GNS ***
 azimuth_ropp =   0.000000000000000E+000
 azimuth_gpac =   0.000000000000000E+000

 *** LEO due south of GNS ***
 azimuth_ropp =   0.000000000000000E+000
 azimuth_gpac =    180.000000000000     

So as long as clockwise azimuths are reckoned positive (as for bearings), then it's the gpac version that's right. (And ROPP is irredeemably wrong in the last case.)

We need to ensure this doesn't undo the correction implemented in ROPP5.1 as described in #233. And, of course, that it doesn't mess up the test folder.

[Ian Culverwell]

test_azimuth.txt

[Ian Culverwell]

For the first pic of #233, azi.f90 gives

LEO at (-25E, 55N); GNS at (0E, -50N):
 azimuth_ropp =    169.628895631531     
 azimuth_gpac =    349.628895631531     

GPAC is therefore closer to the definition of azimuth as "GNS-to-LEO line of sight wrt North". It differs by 180 deg from the ROPP value. (The UCAR value is close to the ROPP value.)

For the second pic of #233, azi.f90 gives

LEO at (-40E, 60N); GNS at (-170E, 5N):
 azimuth_ropp =    250.986625876981     
 azimuth_gpac =    70.9866258769807     

Again, GPAC and ROPP differ by 180 deg, and again GPAC is closer to the "GNS-to-LEO bearing from North" definition. (The UCAR value differs by a physically insignificant 360 deg from the ROPP value.)

Note that early (pre-5.1) versions of ROPP would have calculated an azimuth of 109 deg in the second case, which is pants by anyone's definition, so #233 was definitely correcting an error. But the GPAC algorithm agrees with the ROPP definition, and appears to be more reliable (see the idealised tests at lon=lat=0 above), so I think we should adopt it. This has been done at r4201.

[Ian Culverwell]

Chris has agreed we should adopt the GPAC azimuth algortithm, so closing the ticket.