id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
325	Recalculation of azimuth in ROPP	Ian Culverwell	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.
"	defect	closed	normal	8.0	ropp_utils	7.0	fixed	azimuth