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)
Change history (3)
comment:1 by , 15 years ago
Milestone: | 4.0 → 4.1 |
---|
comment:2 by , 15 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
Input from Stig (15/10/09):
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.