| commit | a60c4674697f658a0ad7213f385ae271bb8d64ad | |
| author | Jim Bresch <bresch@ucar.edu> | |
| Sun, 14 Jan 2018 05:37:55 +0000 (13 22:37 -0700) | ||
| committer | Jim Bresch <bresch@ucar.edu> | |
| Sun, 14 Jan 2018 05:37:55 +0000 (13 22:37 -0700) | ||
| tree | ac60d40d9362f89f41a7c7054c7b93cd53265bbf | treesnapshot (tar.gz zip) |
| parent | 6a89f89c64259094b0d9c3aeae44cf569a0f7b70 | commitdiff |
Add capability to ungrib RDA's ECMWF ds113.1 (9km) output.
The high-resolution EC output are stored in a non-standard grib1
file. The record-length is larger than can be stored by the 3-byte
header record, so EC created a hack to the header which breaks
ungrib. Decoding it properly would require reverse-engineering
NCEP's wgrib C code and adding it to ungrib. The simplest
work-around is to use wgrib to determine the record-length and
feed that to ungrib. This is done via the new ec_rec_len namelist
variable (default of zero). Most of the code changes are to pass
the ec_rec_len down to the low-level grib routines that need
the record length. The value for ec113.1 is 26214508 and should
be constant. If they create an even higher-resolution dataset then
we'll feed that to ungrib using ec_rec_len.
The high-resolution EC output are stored in a non-standard grib1
file. The record-length is larger than can be stored by the 3-byte
header record, so EC created a hack to the header which breaks
ungrib. Decoding it properly would require reverse-engineering
NCEP's wgrib C code and adding it to ungrib. The simplest
work-around is to use wgrib to determine the record-length and
feed that to ungrib. This is done via the new ec_rec_len namelist
variable (default of zero). Most of the code changes are to pass
the ec_rec_len down to the low-level grib routines that need
the record length. The value for ec113.1 is 26214508 and should
be constant. If they create an even higher-resolution dataset then
we'll feed that to ungrib using ec_rec_len.