unit_conversion problems on longitudes and latitudes

[Ian Culverwell]

The transcription of the MT-IO-02 test from the test folder to a new suite has revealed that the ROPP unit conversion utilities are failing on latitudes and longitudes. For example, if we take the input file MT-IO-02.nc, which has

		lat:long_name = "Reference latitude for the occultation" ;
		lat:units = "degrees_north" ;
		lat:valid_range = -90., 90. ;
 lat = 67.0613, 67.0613 ;

then manually amend this (with NC operators) so that MT-IO-02.3.nc holds

		lat:long_name = "Reference latitude for the occultation" ;
		lat:units = "radians" ;
		lat:valid_range = -1.5707963267949, 1.5707963267949 ;
 lat = 1.170441, 1.170441 ;

and then pass the latter through ropp2ropp, we find that the resulting file MT-IO-02.4.nc has

		lat:long_name = "Reference latitude for the occultation" ;
		lat:units = "degrees_north" ;
		lat:valid_range = -1.5707963267949, 1.5707963267949 ;
 lat = 1.170441, 1.170441 ;

The units have been correctly renamed, but the data and valid_ranges have not been rescaled.

Ditto for lat_tp.

If I try to do a similar thing with longitude, by converting

		lon:long_name = "Reference longitude for the occultation" ;
		lon:units = "degrees_east" ;
		lon:valid_range = -180., 180. ;
 lon = 39.74173, 39.74173 ;

to

		lon:long_name = "Reference longitude for the occultation" ;
		lon:units = "degrees_west" ;
		lon:valid_range = 180., -180. ;
 lon = -39.74173, -39.74173 ;

and passing the latter through ropp2ropp, I find

		lon:long_name = "Reference longitude for the occultation" ;
		lon:units = "degrees_east" ;
		lon:valid_range = -180., 180. ;
 lon = -39.74173, -39.74173 ;

This time the valid_range has been correctly scaled (flipped), but the data values still haven't.

Ditto for lon_tp.

As far as I can see these are the only issues with the MT-IO-02 tests. All the other sclaings and unscalings (descalings?) match within numerical precision. Azimuth{_tp}, which might be expected to get messed up, looks OK, even if the numbers in the input file are inconsistent:

	float azimuth(dim_unlim) ;
		azimuth:long_name = "GNSS->LEO line of sight angle (from True North) for the reference coordinate" ;
		azimuth:units = "degrees_T" ;
		azimuth:valid_range = 0., 359.9 ;
azimuth = 0.433944, 0.433944 ;

and

	float azimuth_tp(dim_unlim, dim_lev1b) ;
		azimuth_tp:long_name = "GNSS->LEO line of sight angles (from True North) for tangent points" ;
		azimuth_tp:units = "degrees" ;
		azimuth_tp:valid_range = 0., 20620.7510467583 ;
azimuth_tp =
  114.5916, 114.5916, ...

This should be fixed while we're at it.

[Ian Culverwell]

Test datasets and run script (see mt-io-02) now attached.

[Ian Culverwell]

It turns out that the lat and lat_tp issues have already been fixed in r5688. As a result of this, when MT-IO-02.3.nc is passed through ropp2ropp we find, as expected:

		lat:long_name = "Reference latitude for the occultation" ;
		lat:units = "degrees_north" ;
		lat:valid_range = -90., 90. ;
lat[0]=67.0613 
lat[1]=67.0613

Similarly for lat_tp.

[Ian Culverwell]

The variable azimuth is also OK.

Input:

		azimuth:long_name = "GNSS->LEO line of sight angle (from True North) for the reference coordinate" ;
		azimuth:units = "degrees_T" ;
		azimuth:valid_range = 0., 359.9 ;
azimuth[0]=0.433944 
azimuth[1]=0.433944

After manual adjustment:

		azimuth:long_name = "GNSS->LEO line of sight angle (from True North) for the reference coordinate" ;
		azimuth:units = "radians" ;
		azimuth:valid_range = 0., 6.28143997792759 ;
azimuth[0]=0.00757375 
azimuth[1]=0.00757375

After passing this through ropp2ropp:

		azimuth:long_name = "GNSS->LEO line of sight angle (from True North) for the reference coordinate" ;
		azimuth:units = "degrees_T" ;
		azimuth:valid_range = 0., 359.9 ;
azimuth[0]=0.433944 
azimuth[1]=0.433944

[Ian Culverwell]

azimuth_tp is a bit weird. The default units are degrees rather than degrees_T, as is the case for azimuth. This should probably be fixed at some point. The numbers are crazy (and inconsistent with the values of azimuth), but they are processed by ropp2ropp OK.

Input (MT-IO-02.nc):

		azimuth_tp:long_name = "GNSS->LEO line of sight angles (from True North) for tangent points" ;
		azimuth_tp:units = "degrees" ;
		azimuth_tp:valid_range = 0., 20620.7510467583 ;
azimuth_tp[0]=114.592 
azimuth_tp[3137]=114.592

Manual adjustment (MT-IO-02.3.nc):

		azimuth_tp:long_name = "GNSS->LEO line of sight angles (from True North) for tangent points" ;
		azimuth_tp:units = "radians" ;
		azimuth_tp:valid_range = 0., 359.9 ;
azimuth_tp[0]=2 
azimuth_tp[3137]=2

Result of passing through ropp2ropp (MT-IO-02.4.nc):

		azimuth_tp:long_name = "GNSS->LEO line of sight angles (from True North) for tangent points" ;
		azimuth_tp:units = "degrees" ;
		azimuth_tp:valid_range = 0., 20620.7510467583 ;
azimuth_tp[0]=114.592 
azimuth_tp[3137]=114.592

(Clearly the valid_ranges are 180/pi times too big.)

[Ian Culverwell]

test1.sh

[Ian Culverwell]

Further test script test1.sh attached.

[warrick]

Regarding the degrees west to degees east problem, ROPP does convert the units correctly, but the converted units later get overwritten with the original values. The problem happens at line 1522 of the attached file ncdf_getvar.f90, because it overwrites if it finds values less than 180, more than -180:

if(rvalues < rrange(1) .or. rvalues > rrange(2)) values = rvalues

The longitude range 180,-180 in the test file MT-IO-02.3.nc is technically incorrect, as the range should still be -180,180 even with longitude in degrees west. The attached code includes fixes for degrees west with the range either way round (-180,180 is used in MT-IO-02.3_new.nc). The fixes make sure the variables 'range' and 'rrange' are the correct way round and are at lines 1458-1462 and 1505-1509:

         if (rrange(1) > rrange(2)) then
            range_temp = rrange(1)
            rrange(1) = rrange(2)
            rrange(2) = range_temp
         endif

         if (range(1) > range(2)) then
            range_temp = range(1)
            range(1) = range(2)
            range(2) = range_temp
         endif

So one solution would be to copy that fix for all 49 subroutines in ncdf_getvar.f90. Alternatively there may be a neater solution involving editing the macro (.m4) files that generate ncdf_getvar.f90.

Since there is no immediate urgency to fix this issue, we suggest deferring it to 'Whenever' status until ROPP10.0 development is finished.