Opened 16 years ago

Closed 15 years ago

#171 closed defect (invalid)

Thinning of profiles spanning 0deg/180deg or poles

Reported by: Dave Offiler Owned by: Dave Offiler
Priority: normal Milestone: 4.1
Component: ropp_io Version: 3.0
Keywords: Thinner, interpolation, latitude, longitude, azimuth Cc: Huw Lewis

Description

From reviewing the draft GRS8 (ROPP Thinner Algorithm description), Stig has fed back an issue with profile longitudes spanning 0deg or 180deg or going over one of the poles. In these cases, the interpolation either side of the critial point (say -179.9 and +179.9) would result in an incorrect output (0deg in this example).

In the present code, an attempt has been made to transform the longitude range prior to interpolation, and restoration after, but this just shifts the problem around the globe. There is no guard against profiles spanning the pole.

Also related is the azimuth angle, which in principle could span either side of due North.

While relatively rare, these cases can occur, so should be processed correctly. This is not a show-stopper for release ROPP-3, but should be noted as a limitation in the RN and fixed before the next release.

Attachments (1)

ropp_thinner_latlon_summary.doc (77.5 KB ) - added by Huw Lewis 15 years ago.
Lat/lon test cases

Download all attachments as: .zip

Change history (3)

comment:1 by Huw Lewis, 15 years ago

Milestone: 4.04.1

Input from Stig (15/10/09):

Not so easy to explain. But yes, one way would be a transform to 6 cartesian coordinates (3 for
position and 3 for ray direction). Another one involving quaternions describing rotations (4 
coordinates) would be possible, but then one would have to hold track of a possible sign-change 
and swap the sign on parts of data before interpolation (a time series of quaternions may change
 the sign at 'apparently' random places, depending on the angles of rotation).



I haven't looked closer at it since the below email exchange, although I did try find cases 
where it failed for MetOp, but was not able to. And I did see that for normal (50Hz) sampling 
the TP track would have to pass extremely close to the pole to be a real problem. I think Dave 
is right that it is very rare.



I see that I promised to suggest and implement the change (and test it) for ROPP-4! I'm sorry 
that I didn't. I certainly had the intention. If okay with you I suggest we postpone it to 
ROPP-5.

No update to code attempted given unsufficient time to fully test any implementation before release. Limitations section of release notes for ROPP-4 still highlights this as a potential problem, though rare.

Optimistically move ticket to planned ROPP-4.1 development, when more opportunity for testing (and perhaps we will have a real case of this to work with).

Ticket remains open, move to 4.1.

by Huw Lewis, 15 years ago

Lat/lon test cases

comment:2 by Huw Lewis, 15 years ago

Resolution: invalid
Status: newclosed

The attachment shows a few examples showing the behaviour of the ROPP thinner for certain latitude/longitude configuations.

My investigations show that the current implementation has no problems for occultations crossing +/-180 degrees. Further, a 'spike' in longitude is only present for a pole-crossing occultation (should one be possible), when using Savitsky-Golay pre-smoothing (this does NOT therefore affect the operational implementation at EUMETSAT and DMI).

I don't propose that we try to find a fix for the Sav-Golay implementation [unless SG thinning becomes operational], given this is not the default thinning method suggested and that polar crossings are rare (if at all possible). It is also likely that any fix will complicate the nicely generic thinner routines.

Ticket closed as 'invalid', and new ticket to be created to highlight the minor SG outlier issue.

Note: See TracTickets for help on using tickets.