Increase centre of curvature range limits

[Ian Culverwell]

Christian Marquardt (EUM) reports a problem from a user:

Dear Josep,

I’ve added Ian and Kent (for the ROPP) as well as Harald to the 
list (as I think he’s the IROWG bufr guru).

Some background: the test data streams on the ftp server 
(GRAS_Geometrical_Optics and GRAS_Wave_Optics) are fed by our 
prototype system. The GRAS_NRT data stream on the ftp server is fed 
by the operational software in our validation ground segment. 
Scientifically and with respect to the bending angle profiles, the 
prototype and operational code provide the same results (when using 
equivalent versions); but there are some technical differences. One 
is the generation of bufr; we use the ROPP in the prototype setup, 
but an internal solution in the operational code. In this case, I 
believe the problem is in the ROPP

You are right that the bufr files has missing components in r_coc; 
values are:

   r_coc =  20459.17, -9.9999e+07, 12089.03 ;

The original  level 1b product however has 

     r_curve_centre_fixed = 20459.1650542901, 82510.4888887256, 
        12089.0251200038 ;

so the bufr version has the correct numbers, but the second 
coordinate must have been set to missing in the conversion process. 
The ROPP we use appears to use a valid_range for the CoC 
coordinates of [-50000, 50000] meters, but the coordinate affected 
has 82500 meters – that is why it was set to invalid I presume.

@Ian, @Kent: Is there a reason for the range limitation in ROPP? 
Should we update the valid_range in the next ROPP release? If you 
could suggest a better choice we would update our ROPP installation 
accordingly.

@Harald: I haven’t found any reference to valid ranges for the CoC 
in the bufr specification, but I tend to overlook such subtleties. 
Do you think there is a limitation? Should there be one?

We will check what the operational code does; my assumption is that 
it copies values correctly into the bufr, but postprocessing with 
the ROPP tools might again re-introduce the missing data values. 
And right now, we don’t have a bufr reader other then the ROPP. 
I’ll let you know about the outcome.

@Josep, thanks again for making us aware of this bug, and please go 
on doing that!

   Chris.

[Ian Culverwell]

GRAS_1B_M01_20160614052210Z_20160614052219Z_N_T_20160614090313Z_G27_ND.bufr

[Ian Culverwell]

I replied:

Hi Chris,

Thank you for letting us know about this.

You are of course correct that it is the ROPP range-checking which is nullifying
y_coc in this case.   (I looked in the ROPP ropp2bufr converter and the only
limitation on the BUFR value was that it must be < 1e6 m in absolute value.  I
hope this agrees with the BUFR specification.)

I don't know where the original r_coc ranges of [-50km, 50km] came from.  We can
easily increase them (ropp_io/ropp/ropp_io_types.f90) to, for example, [-100km,
100km].  Would that be acceptable to you all?  If so, I can include it in
ROPP9.0.

I found in Sec 5 of RSR14
(http://www.romsaf.org/general-documents/rsr/rsr_14.pdf) that the maximum
displacement of the centre of curvature wrt the centre of the Earth, |r_coc -
r_coe| was twice the equatorial excess, ie ~ 42 km, but this was after averaging
over all azimuths, so presumably the occasional > 42 km might be possible.  (I
see that the azimuth in this case is ~ 215 deg at 15 deg N, and I suppose a ~N-S
occultation near the equator might see a big displacement of the CoC.)  And,
apparently, you haven't seen this (very often) before.

All: please let me know if you think +/- 100 km would be an acceptable range of
the CoC components.

Kind regards, Ian.

Awaiting input from users to see if the proposed change in range is acceptable.

[Ian Culverwell]

It turns out that this was a mistake on EUMETSAT's side:

Ahh. Now I know.

We have a small number of occultations (single figures per day, as you observed
as well) which are very short; the one you found is only 8 or 9 seconds, for
example. I would think they are all set to degraded (you can recognised that by
the 'D' in the 'ND' part of the file name). For the altitude coverage that means
that they only cover a few kilometers - often high up, and often ending at 60
km. In that case, we currently use the lowest point of the occultation for the
georeferencing.

The problem is that the tangential point we calculate is then not on the
ellipsoid's surface, but, well, 60 km higher. And so we wrongly shift the CoC
for these occultations. When catching this case and redoing the tangential point
on the ellipsoid, I replicate your numbers nicely.

We'll fix that in the test data next week. The operational code might suffer
from it a bit longer until the next formal release; with the number of
occultations affected being so small, and all of them being flagged as degraded
anyway, it's not worth to stop the rollout yet again I'm afraid...

Thanks for spotting that!

-- 
Dr. Christian Marquardt, Radio Occultation Team Leader
EUMETSAT, Eumetsatallee 1, D-64295 Darmstadt, Germany
Tel: +49-6151-8074560, Fax: +49-6151-807304
Email: christian.marquardt@eumetsat.int, Web: http://www.eumetsat.int 

[Ian Culverwell]

Closing ticket as 'wontfix'.