Lat/Lon and azimuth differences between ROPP & UCAR

[Dave Offiler]

Ali Sam reports in Helpdesk ID 72:

The GRAS SAF Helpdesk has received a question from ali sam

The helpdesk subject is:

corrupted output of ropp_pp_occ_tool  compare with COSMIC atmprf data.

The helpdesk description is:

Dear GRAS SAF Team,

1. I used one COSMIC atmphs profile as input of ucar2ropp tool 
and set it's output as input of ropp_pp_occ_tool in directory 
that I run this tools, MSIS_coeff.nc,egm96.dat and corrcoeff.dat
data files were peresent. I compared   lat_tp and lon_tp
parameters (Variable in output file of ropp_pp_occ_tool ) with 
lat and lon parameters (Variable in COSMIC atmprf netcdf file that
was correspond to  used COSMIC atmphs file). result of my work
showed this two sets of parameters did'nt match and phase_qual
(variable in output file of ropp_pp_occ_tool) in many data points
equal -99999000. also bangle_qual, refrac_quality and other
quality  variable in ropp_pp_occ_tool output file had -99999000
values. 

Would you please inform me if it's reasonable or any other
auxilliary data is needed?

2. also I want to know, is input file of ropp_pp_invert_tool and
ropp_pp_spectra_tool, similar to input file of ropp_pp_occ_tool?
if no, please help me.

Regards and thanks.

In order to reply to this helpdesk enquiry please use the link below:

http://www.grassaf.org/helpdesk_answer.php?id=72

This message is sent to the following email addresses: 

oliveras@ieec.fcr.es, grasadm@dmi.dk, grassaf@metoffice.gov.uk 

Our initial reply was:

Dear Ali,

Thanks for your Helpdesk feedback.

1) atmPhs profiles

a) You don't say whether the lat/lon differences are close 
(e.g. within a tenth of a degree) or completely different, 
so it's not possible to give an answer immediately. 
If the values are quite close, it's likely to be because the 
ROPP and UCAR algorithms generate samples on different Impact
Parameter heights - are the IP and BA values different too? 
If they are very different, them we'd need to look at the 
ECF/ECI calculations. Note that ROPP is not required to 
reproduce UCAR's values exactly, though they should be
statistically similar.

In order to investigate further, could you please email us the following:

- an indication of the size of differences in lat/lon that you are finding;
- the pair of UCAR/CDAAC atmPhs and atmPrf files (or their names
  so we can download them from the CDAAC server);
- your configuration file for ropp_pp_occ_tool;
- logs of the output from the ucar2ropp and ropp_pp_occ_tool commands.

For the latter, please use the -d switch to output additional
debug/diagnostic information. We will then try to reproduce and
explain (and if necessary, correct) the differences.

Please email directly to grassaf@metoffice.gov.uk - there is no
need to use the Helpdesk system (unless you have a new issue to
raise).

b) ROPP does not (yet) calculate any of the *_quality parameters,
so these are set to the default value for 'missing data'. 
The method of calculating these quality parameters, and from what
inputs, has yet to be defined. We could consider setting them to a
nominal 100 (percent), but for the present, they cannot be used 
for quality control purposes.

2) Yes, the input to ropp_pp_spectra_tool should be a ROPP
netCDF file converted from - for instance - a UCAR atmPhs file
by ucar2ropp, since this tool requires phase and amplitude data.

But ropp_pp_invert_tool requires L1 & L2 bending angle data, so
the input would be - for instance - a file output by ropp_pp_occ_tool.

I hope this is useful, and if yo can send us the requested files
and other information, we'll investigate the lat/lon issue. 

Best regards,
Dave Offiler
ROPP Development Team
grassaf@metoffice.gov.uk

Awaiting reply from Ali, but in the mean time an arbitrary atmPhs/atmPrf file pair will be investigated (by Chris).

[cburrows]

Ali has provided the data he used (atmPhs_C005.2008.001.19.41.G08_2010.2640_nc and atmPrf_C005.2008.001.19.41.G08_2010.2640_nc) but this issue is not specific to this profile. The bending angle profiles calculated by ROPP and UCAR are quite similar (though the COSMIC profile has been truncated):

The latitudes and longitudes throughout the profile are quite different though, and the tangent point drift calculated by ROPP is almost perfectly straight:

At high levels the lat-longs coincide but closer to the surface they diverge. This highlights the differences in the algorithms used by ROPP and UCAR. In ROPP, the tangent points' latitudes and longitudes are purely geometrical, based on the straight line connecting the GPS and LEO satellites. In the UCAR processing, the bending angle is taken into consideration, giving a more physical interpretation of the tangent point (i.e. the closest approach of the ray). This is clearly more of an issue at low levels where the bending is strongest, and at higher levels the tangent point will tend towards the purely geometrical measure (see plot above).

We could either attempt to make the ROPP algorithm more physical by taking into account the bending angle, or make it clearer to users that the tangent point is defined by the closest approach of the straight line between the satellites.

One further point for future investigation was discovered - the values of azimuth are not consistent with those provided by UCAR. Note that ROPP uses -180 to 180degs and UCAR uses 0 to 360 degs. Despite that, for this occultation, ROPP calculates 141degs and UCAR provides -141degs:

This is probably just a cross product being done the wrong way around or an atan2 issue. This is being looked into.

[cburrows]

Correction - the comment above should say: "Note that ROPP uses 0 to 360 degs and UCAR uses -180 to 180degs."

[cburrows]

All azimuths calculated by ROPP are 0<azim<180. This should be rectified by calculating (r_gns-r_leo).(n X r_tp) where all quantities are vectors, and n is [0,0,1] in ECF coords. If this solution is negative, then the currently produced azimuth should be subtracted from 2pi. Plots etc to follow.

[cburrows]

Here are some map plots to illustrate the issues with the ROPP calculation of the azimuth. First, note that the ECI coordinates from the Phs files have been converted to lat-lons directly (i.e. without converting ECI to ECF), so the map plots do not show the geographical positions - this is purely illustrative and does not affect the conclusions, and also note that the projection doesn't accurately represent the azimuth if the angles between the two satellites is large. Also, the positions of the two satellites are shown purely by mean of their 'lat-lons' throughout the occultation, so their heights are not displayed.

As mentioned above, UCAR defines the azimuth to be between -180 and 180 degrees but ROPP uses the 0 to 360 degree convention.

For an occultation whose azimuth (as calculated by UCAR) is between 0 and 180 degrees, ROPP calculates a similar, but not identical value. This is presumably because in ROPP the straight line tangent altitude is used, but perhaps UCAR use a more refined definition of the tangent point. Such an example is shown below:

Notice, however, that the azimuth calculated seems to describe the clockwise bearing from north going from the LEO satellite to the GPS satellite. This is contrary to the description in the ROPP netCDF header which states that the values are: "GNSS->LEO line of sight angles (from True North) for tangent points". I have been unable to find a statement of how UCAR defines the azimuth, other than that it is an angle from North.

When the azimuth is between -180 and 0 degrees as calculated by UCAR, the corresponding ROPP value is the absolute value of that provided by UCAR (with some small deviation). For example, if UCAR's value is -170 degrees, then ROPP would produce 170 degrees in the 0 to 360 degree convention, so for this example there would be an error of 20 degrees, though errors of up to 180 degrees could be obtained. The plot below is an example of such an occultation:

The angle of 251.7 degrees was produced after a code change to account for such occultations. Previously, the result was 108.3 degrees. The code change required in ropp_utils/coordinates/tangent_point.f90 and occ_point.f90 is as follows:

if (Dot_Product(r_gns(i,:)-r_leo(i,:),vector_product(pa, perigee(i,:))) < 0) then

theta=2.0*Pi-theta

endif

There is still the unresolved issue of whether the azimuth is from GNSS to LEO or vice-versa. For practical purposes this shouldn't (I think) matter when performing 2D forward model calculations, but for completeness, the definition as provided by ROPP should be consistent with the various processing centres (assuming that they are consistent with each other).

[cburrows]

Code change for the azimuth calculation has now been implemented to the 5.1 branch (revision 2971). Ticket will be closed after it has been passed through the ROPP test folder successfully.

[cburrows]

The code change has had the desired effect with no adverse consequences, so this ticket will be closed.