Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#99 closed defect (fixed)

Loss of heights in fixed-height thinning

Reported by: Dave Offiler Owned by: Dave Offiler
Priority: normal Milestone: 1.0
Component: ropp_io Version: 0.9
Keywords: Thinning BUFR Cc:

Description

When using fixed-height thinning (LIN-247), DMI's BUFR is decoding (using the decbufr tool) with the lowest height levels 'missing' in the Lev2a section.

Interpolated parameter values can be set missing when the occultaton profile does not completely span the range of fixed level heights, but in this case, the (fixed) height values should still be present as they are not interoplated. In this anomolous case, the height values are also being set missing. Leve1b Impact Parameters and Lev2b geopotential heights are present, so this only affects Lev2a geometric height levels.

Since the refractivity data is missing (as expected in many cases), the low-leve portion of the profile is anyway unusable, this is not a show-stopper of high-priority.

Change history (5)

comment:1 by Dave Offiler, 18 years ago

The conversion of Impact parameter to geometric Height (in ropp_io_thin.f90) requires the refractivity at that level.

Essentially,

h = a/n - Rc or h = (h' + Rc) / n - Rc

where h' is the impact height, n=(1-N.10-6) and Rc = radius of curvature

Now for an occulation not spanning the range of the (foxed) levels, there are no N's for the interplolation (same for BA; the BUFR has missing BA's, but IP's are present) - and hence are set missing for the above calculation of geometic height. Now the missing data value in the thinner is -9999.9 (say -104). The negative N was causing n to be >1, and - if Rc is big enough - h could be negative. BUFR then iterprets this as missing.

For cases where N is missing, possible solutions include:

1) explicitly set h to missing (same consequences for BUFR as current code, but consistent, and not dependent on the Rc value.

2) set h to some arbitary value(s) - e.g. zero, just to have a non-missing value (MetDB seems to lose proper count levels in a profile where all parameters are missing at any 'level')

3) set N to some arbitrary, non-missing value

a) zero b) a single nominal value appropriate to around 3km, c) lowest good value d) extrapolated N profile e) ...

Since the refractivity is missing, an accurate value for h is not necessary. Retaining missing h values might be confusing for users, and seems to cause MetDB some too, so (1) is not recommended. It would be desirable to have a nominal 'profile' with indicative altitudes, so (2) would have to generate a nominal set (which could be a set of levels between some lower value and up to the first non-missing h). (3) does this more neatly and would generate a more realistic set of levels, especially with a good approximation for the missisng N.

As a compromise, option 3c seems reasonable.

comment:2 by Dave Offiler, 18 years ago

Solution: implement option 3a in ropp_io_thin.f90

In both the pre-conversion of original h levels to impact parameter for thinning, and post-conversion of thinned impact parameter levels back to h:

  • initialise n to unit at the top of the profile.
  • scan downwards (assuming the profile is in asceding height order)
  • if N > 0, calculate a new n for that level
  • else leave previous good value for n unchanged
  • calculate h as before

Tested on recent sample .nc file provided by Martin that was known to have missing hights in the BUFR. Run current ropp2bufr and confirmed missng N heights at lowest 10 levels suing decbufr tool to dump decoded output. (Same as for BA values, where IP's are present). Rebuilt ropp_io with modified code and re-run on test file test. Confirmed that N-level heights are now present and have believable values. Compared with original profile and N values and heighst are consistent with interpolation between closest original levels.

Committed as changeset [1001]

Modifed code to be provided to Martin and rechecked with live test data over GTS.

comment:3 by Dave Offiler, 18 years ago

The implemented option in the prvious Ticket change was a typo: is should have read Option 3c (use the last good N value in the height calculation).

1) Spotted & corrected a bug in calculation of n = ( 1 + N.10-6 ) where the code (and the quoted equation above) had a '-' instead of '+'.

2) Option 3c actually didn't do a very good job as the refractivity is changing rather rapidly at lower levels, so significantly underestimates the real refractivity by a factor orf 2-3. Algorithm changed to perform a log interploation between the last good value (as described above) and an assumed N=300 at H=0.

The combination of these two changes gives much more realistic nominal height values (remembering that the refractivy on these levels is still 'missing') if they were to be used e.g. for statistical counting purposes.

Committed as [1007]

Still to be tested at DMI before closure.

comment:4 by Dave Offiler, 18 years ago

Resolution: fixed
Status: newclosed

Sean has had a look at some of the DMI BUFR data, and doen't report anything wrong. We'll call this fixed, but re-open if any problems arise in processing real GRAS data.

comment:5 by Dave Offiler, 18 years ago

Version: 0.9
Note: See TracTickets for help on using tickets.