Opened 16 years ago
Closed 16 years ago
#145 closed defect (fixed)
Review valid ranges
| Reported by: | Huw Lewis | Owned by: | Huw Lewis |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.0 |
| Component: | ropp_io | Version: | 1.0 |
| Keywords: | Cc: | dave.offiler@… |
Description (last modified by )
Analysis of MT-IO-01 results shows an error in temp_sigma comparisons using ropp2bufr and bufr2ropp successively. This is due to the random valid data in the input file (randomly generated by test2ropp) being over the valid range allowed in the bufr file. This highlighted that at least some of the quoted valid ranges for variables (ROPP defaults) are NOT consistent with those allowed in the BUFR files.
A review of the quoted valid ranges in the User Guide documentation and set as defaults in ropp_io_types is required. Valid ranges must be consistent with those allowed in BUFR.
- Review valid ranges
- Update ropp_io_types with appropriate valid ranges
- Generate new test data files with v2.0 valid ranges quoted
- Update User Guide (Part I) and Interface File Format document
Change history (5)
comment:1 by , 16 years ago
| Description: | modified (diff) |
|---|
follow-up: 3 comment:2 by , 16 years ago
comment:3 by , 16 years ago
Replying to frhl:
Here is a summary of the valid ranges listed in ROPP code and user guide (UG), interface file format document (IFF) and as allowed in BUFR.
First to note that in the BUFR document, the quoted ranges in the Comments column were meant to reflect the nominal range (user requirement) and not the max. range possible with the defined bit width/scale/offset, nor the range limits imposed by any particular code implementation (this is not an ROPP document but generic for anyone's code). The UG, on the other hand, should reflect what the code limits are; the IFF is a bit in-between, but probably more UG than BUFR.
Secondly, the range limits in ropp2bufr are not (in general) the same as those defined in ropp_io_types, or checked in ropp_io_rangecheck(). The former reflect more the wider range (in some cases) that BUFR can handle without giving an error in the low-level encoder library. The limits here can be a little more generous than the ROPP defaults which define neat, round-number values (e.g. 5.0 when BUFR can handle 5.1)
Please comment where necessary on required actions (see ). I propose calling the updated Interface File Format document Version 2.0 to reflect the changes to some of the valid ranges (and now consistent with v2.0 code). I propose calling the updated BUFR specification document (if needed) v2.0 (currently v1.9)
The BUFR document is completely independent of the ROPP release (and is not a ROPP document), so would be v2.0 only if changed and so naturally incremented from v1.9; this number would be purely coincidental to ROPP v2.0.
The IFF document version number is v1.1 reflecting the FORMAT ID. For this document only, there is an ISSUE number which would be incremented (to Issue 4).
year: UG 1999 - 2099 Code 1995 - 2099 IFF 1995 - 2099 BUFR n/aAction - Edited UG Action - Edit typo in IFF for year of verification time (1990 - 2099)
BUFR can handle 0-4094 (12bits). ROPP should be capable of handling the oldest RO data (GPS/MET) which I think was 1995. It would do no harm to consistently have a lower limit of 1990.
fcperiod: UG 000 - 240 hours Code 0 - 24 hours IFF 0 - 24 hours BUFR n/aAction - Edited UG
No BG info in BUFR (experience of including BG in other data types shows it to be overly complicated and no-one wanted it anyway!). 0-24hr should be adequate for netCDF.
time_offset: UG 0 - 999.999 s Code 0 - 599.999 s IFF 0 - 599.999 s BUFR 'Time increment 0-200 s (to 1ms)' (ropp2bufr code checks 0-240 s)Action - should valid range be revised to 0 - 199.999 s? N.B. Same contradiction for 'time since start' in Lev 1b (UG cf code+IFF), but this variable not used in BUFR.
We should be able to cope with the longest occultation. Nominally, these are ~1minute, possibly 2min for off-centre views. I think it was Chris who suggested going up to 4min max.
BUFR can handle -4.096 to +258.046 secs (18 bits/scale 3/offset -4096) or 0-240s in round numbers.
IIRC, -999.999 was just an arbitrary limit for >=1000s to be 'missing'; 599.999 was 'missing if >10minutes'. We could consistently go for 200s or 240s (the latter updating the BUFR doc consistently with the code, though the BUFR doc is meant to represent a nominal minimum user requirement and in practice we allow a bit more).
roc: UG 6.2 - 6.6 x 10^6 m Code 6.2 - 6.6 x 10^6 m IFF 6.2 - 6.6 x 10^6 m BUFR 6.2 - 6.6 x 10^6 m BUT ropp2bufr code checks for valid data between 6.25 and 6.45 x 10^6.Action - is the true range allowed in BUFR 6.2 - 6.6 or smaller than this? If not, ropp2bufr needs updating to check the larger range. If so, valid range needs changing and all documentation. N.B. All other valid ranges 6.2-6.6 x 106 (i.e. impact parameter) are checked in this wider range in ropp2bufr - why is roc different?
The BUFR offset (min allowed value) is 6.2x106 metres - with 22 bits/scale 1 the upper limit is actually 6.6194392x106m. So 6.2-6.6 is within BUFR encoding limits. In this case, the ropp2bufr code is the odd one out and can be brought into line (I can't recall why the limits here are tighter; this code pre-dates ROPP, so may reflect our protoptype BUFR template with these limits) So no docs or default ranges need changing.
phase: UG +- 10000 m [v1.2 update] Code +- 10000 m IFF 0 - 1500 m BUFR n/aAction - edit IFF (L1 and L2). This wasn't updated at v1.2 update.
As long as the (format v1.1) text file can handle this field width (F12.5), and it's just the IFF doc range being out of date, then edit appropriately. The field width should be able to handle the missing data value (" -9999.99999"?) so should cope with +/-10000 ok.
v_leo: UG +- 10000 m/s Code +- 10000 m/s IFF +- 100000 m/s BUFR code checks +- 10737Action - edit IFF (assumed typo)
Yes, this looks like a typo, although LEO velocities are higher than GPS ones. BUFR uses the maximum 31 bits for both. (the actual max would be +/- 10737.41822 m/s), so the IFF range would break the BUFR limits.
bangle: UG -0.001 - 0.1 rad [v1.2 update] Code -0.001 - 0.1 rad IFF -0.0001 - 0.05 rad BUFR -0.001 - 0.06 rad N.B. ropp2bufr checks in range -0.0001 to 0.06 radAction - the updated upper valid range for bangle is NOT consistent with BUFR limits. Suggest we have to revise upper limit for bangle back down to 0.05 rad (despite feedback from Stig asking to extend for v1.2). Any other ideas? Action - BUFR document needs editing to indicate -0.0001 to 0.06 rad check (was the different lower limit just a typo?).
With an offset of -100,000, scale 8, 23 bits, the actual BUFR encoding limits are -1x10-3 (-0.001) to 8.288604x10-2 (0.08286). (BUFR doc has 10-3 to 6x10-2; this lower limit is consistent & correct)
The IFF limit needs changing to 0.001 - 0.06; ropp2bufr lower limit to 0.001.
We would need to re-check with Stig, but there could be some compromise between the upper limits used for netCDF and BUFR. We could push BUFR (ropp2bufr) out to 0.082 but not 0.1.
The lower limit can/should be 0.001 everywhere.
height: UG -1000 - 100000 m Code -1000 - 100000 m IFF -1000 - 100000 m BUFR 0 - 100 km but ropp2bufr checks -1 - 100 kmAction - suggest BUFR document needs editing for all height variables in Lev2a, Lev2b and Lev2c to indicate valid range in BUFR goes down to -1km. Note this is a bit confusing as the table B ref val is -1000 (i.e. valid range of data in BUFR file would really be 0 to 101 km - I think it's clearer to indicate the 'true' valid range though, as done for roc and bangle in the BUFR document for example.
The BUFR offset is quoted as -1000 (-1km) and with 17 bits/scale 3 the actual upper limit is +130070m (130km); the range in the comments column is meant to cover the nominal user requirement, but could be extended at the lower end.
press_sigma: UG 0 - 50 hPa Code 0 - 50 hPa IFF 0 - 50 hPa BUFR 0 - 5 hPa (code checks 0-6.2 hPa)Action - change valid range in ROPP to 0-5 hPa. Update code, documentation and test files for v2.0.
Again, 0-5 is the nominal limit; BUFR can actually go a bit higher. In general, the code checks in ropp2bufr reflect the BUFR capability, not the nominal rangecheck() range. In practice, the ropp2bufr are a back-stop (e.g. if the rangecheck() upper limit really was 50hPa)
temp_sigma: UG 0 - 50 K Code 0 - 50 K IFF 0 - 50 K BUFR 0 - 5 K (code checks 0-6.2 K)Action - change valid range in ROPP to 0-5 K. Update code, UG and IFF documentation and test files for v2.0.
Same comment as for press_sigma.
shum_sigma: UG 0 - 10 g/kg Code 0 - 10 g/kg IFF 0 - 5 g/kg BUFR 0 - 5 g/kg (code checks 0-5.1 g/kg)Action - change valid range in ROPP to 0-5 g/kg. Update code, UG documentation and test files for v2.0.
Actual upper BUFR limit is 5.1; this is consistent with practice for other parameters.
press_sfc: UG 900 - 1100 hPa Code 250 - 1100 g/kg IFF 250 - 1100 g/kg BUFR 900 - 1100 g/kg (code checks 800-1500 hPa)Action - update to valid lower limit of press_sfc to 250 hPa was not consistent with BUFR. This is a pain as 800 hPa is still a bit too high (pressure on Everest ~400 hPa?). Is this a case where ROPP can diverge from BUFR, or should we restrict the range to 800-1100 hPa?
The BUFR template used the same descriptor for 'profile' and 'surface' pressure, so can handle the same range (actually 0.1 to 1100hPa). The only limit specific to surface pressure is in the code. It could be changed to 250 in the documentation and in ropp2bufr. (The BUFR document comment colum again just reflects nominal UR, not raw capability).
press_sfc_sigma:UG 0 - 50 hPa Code 0 - 50 hPa IFF 0 - 50 K BUFR 0 - 5 hPa (code checks 0-6.2 hPa)Action - change valid range in ROPP to 0-5 hPa. Update code, UG and IFF documentation (plus fix units typo) and test files for v2.0.
As for other *_sigma parameters.
comment:4 by , 16 years ago
Updated ropp3bufr code to check data within full available range from -0.0001 rad to 0.082 rad. See [1814].
ROPP user guide and interface file format documents updated to reflect agreed valid ranges.
Ticket remains open until BUFR format document updated.
comment:5 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Here is a summary of the valid ranges listed in ROPP code and user guide (UG), interface file format document (IFF) and as allowed in BUFR.
Please comment where necessary on required actions (see ). I propose calling the updated Interface File Format document Version 2.0 to reflect the changes to some of the valid ranges (and now consistent with v2.0 code). I propose calling the updated BUFR specification document (if needed) v2.0 (currently v1.9)
year: UG 1999 - 2099 Code 1995 - 2099 IFF 1995 - 2099 BUFR n/aAction - Edited UG Action - Edit typo in IFF for year of verification time (1990 - 2099)
Action - Edited UG
Action - should valid range be revised to 0 - 199.999 s? N.B. Same contradiction for 'time since start' in Lev 1b (UG cf code+IFF), but this variable not used in BUFR.
Action - is the true range allowed in BUFR 6.2 - 6.6 or smaller than this? If not, ropp2bufr needs updating to check the larger range. If so, valid range needs changing and all documentation. N.B. All other valid ranges 6.2-6.6 x 106 (i.e. impact parameter) are checked in this wider range in ropp2bufr - why is roc different?
Action - edit IFF (L1 and L2). This wasn't updated at v1.2 update.
Action - edit IFF (assumed typo)
Action - the updated upper valid range for bangle is NOT consistent with BUFR limits. Suggest we have to revise upper limit for bangle back down to 0.05 rad (despite feedback from Stig asking to extend for v1.2). Any other ideas? Action - BUFR document needs editing to indicate -0.0001 to 0.06 rad check (was the different lower limit just a typo?).
Action - suggest BUFR document needs editing for all height variables in Lev2a, Lev2b and Lev2c to indicate valid range in BUFR goes down to -1km. Note this is a bit confusing as the table B ref val is -1000 (i.e. valid range of data in BUFR file would really be 0 to 101 km - I think it's clearer to indicate the 'true' valid range though, as done for roc and bangle in the BUFR document for example.
Action - change valid range in ROPP to 0-5 hPa. Update code, documentation and test files for v2.0.
Action - change valid range in ROPP to 0-5 K. Update code, UG and IFF documentation and test files for v2.0.
Action - change valid range in ROPP to 0-5 g/kg. Update code, UG documentation and test files for v2.0.
Action - update to valid lower limit of press_sfc to 250 hPa was not consistent with BUFR. This is a pain as 800 hPa is still a bit too high (pressure on Everest ~400 hPa?). Is this a case where ROPP can diverge from BUFR, or should we restrict the range to 800-1100 hPa?
Action - change valid range in ROPP to 0-5 hPa. Update code, UG and IFF documentation (plus fix units typo) and test files for v2.0.