Opened 19 years ago
Closed 13 years ago
#52 closed defect (fixed)
Too many levels in BUFR for MetDB
Reported by: | Dave Offiler | Owned by: | Dave Offiler |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | ropp_io | Version: | 0.9 |
Keywords: | BUFR | Cc: |
Description
GFZ data in ROPP v1.0 (TEXT) is provided with 350-400 levels (samples) in the Level 1b, Level 2a and Level 2b sections. MetDB can only handle up to 379 on extraction due to fixed array sizes. Higher nos. of levels can be ingested, but not extracted again from MetDB - and in fact prevent smaller profiles (e.g. from UCAR) from being extracted too.
Solution: limit no. of levels in BUFR for MetDB to no more than 375.
Change history (5)
comment:1 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:4 by , 13 years ago
Owner: | set to |
---|---|
Status: | reopened → assigned |
comment:5 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Note:
See TracTickets
for help on using tickets.
While awating a 'proper' thinning implementation, ropp2bufr merely sub-sampled the input profile to ~200, but assuming the input was hi-res (of order 5000 samples), sampled 1-in-N triggered by there being >400 samples (ie >2x the desired number). For profiles <=400, no thinning was done. This allowed GFZ data 350-400 samples to go through unthinned. Also, only the Level 1b profile was potentially thinned, assuming Level 2a,b profiles would already be lo-res.
The thinning algorithm in ropp2bufr has now been modified to:
This thinning is applied to all three sections containing profiles.
Diagnostic output, help text and man page (ropp2bufr.1) updated to reflect the new -p switch and its application.
GFZ ROPP files now being encoded with default 375 max. levels; tested ok in MetDB extract and being used as from 22 Feb.