[gradsusr] Problem reading sub-hourly WRF grib files (NCEP code table for 15/30 min records)

Wed Nov 22 09:27:24 EST 2017

Sorry for being late the the party. If I have correctly interpreted the messages in this thread so far, Wesley has established that cnvgrib is not working properly for the conversion from grib1 to grib2 because it can’t deal with a 30-minute time unit and messes up the time metadata in the grib2 files. So forget grib2; you must use your data in grib1 format.

I can get GrADS to read this data using the descriptor file copied below.

dset ^%ch
options template
chsub 3 3 WRFPRS_d01.00_20
chsub 4 4 WRFPRS_d01.00_30
dtype grib
index ^WRFPRS_d01.idx
undef 9.999E+20
title WRF sample
pdef 149 149 lccr -29.363000 45.203000 1 1 -21.633000 -21.633000 54.288000 12000 12000
xdef 149 linear 45.203000 0.12517162785946
ydef 149 linear -29.363000 0.109090909090909
zdef 25 levels 1000 975 950 925 900 875 850 825 800 775 750 700 650 600 550 500 450 400 350 300 250 200 150 100 50
tdef 4 linear 00Z17nov2017 10mn
vars 82
*SNOHF10m  0 229,105,10 ** 10 m above ground Snow phase-change heat flux [W/m^2]
*MAXREF1000m  0 235,105,1000 ** 1000 m above ground Hourly max of sim. reflect at 1km AGL [dbZ]
*MXUPHL2000_5000m   0 236,106,12820 ** 2000-5000 m above ground Hourly max updraft helicity 2-5km AGL [m^2/s^2]
*MAXUVV400_1000mb  0 237,101,10340 ** 400-1000 mb Hourly max upward vert vel in lowest 400mb [m/s]
*MAXDVV400_1000mb  0 238,101,10340 ** 400-1000 mb Hourly max downward vert fel in lowest 400mb [m/s]
no4LFTX180_0mb  0 132,116,46080 ** 180-0 mb above gnd Best (4-layer) lifted index [K]
ACPCPsfc  0 63,1,0  ** surface Convective precipitation [kg/m^2]
APCPsfc  0 61,1,0  ** surface Total precipitation [kg/m^2]
CAPEsfc  0 157,1,0  ** surface Convective Avail. Pot. Energy [J/kg]
CAPE90_0mb  0 157,116,23040 ** 90-0 mb above gnd Convective Avail. Pot. Energy [J/kg]
CAPE180_0mb  0 157,116,46080 ** 180-0 mb above gnd Convective Avail. Pot. Energy [J/kg]
CAPE255_0mb  0 157,116,65280 ** 255-0 mb above gnd Convective Avail. Pot. Energy [J/kg]
CDCONclm  0 72,200,0 ** atmos column Convective cloud cover [%]
CFRZRsfc  0 141,1,0  ** surface Categorical freezing rain [yes=1;no=0]
CICEPsfc  0 142,1,0  ** surface Categorical ice pellets [yes=1;no=0]
CINsfc  0 156,1,0  ** surface Convective inhibition [J/kg]
CIN90_0mb  0 156,116,23040 ** 90-0 mb above gnd Convective inhibition [J/kg]
CIN180_0mb  0 156,116,46080 ** 180-0 mb above gnd Convective inhibition [J/kg]
CIN255_0mb  0 156,116,65280 ** 255-0 mb above gnd Convective inhibition [J/kg]
CPRATsfc  0 214,1,0  ** surface Convective precip. rate [kg/m^2/s]
CRAINsfc  0 140,1,0  ** surface Categorical rain [yes=1;no=0]
CSNOWsfc  0 143,1,0  ** surface Categorical snow [yes=1;no=0]
DLWRFsfc  0 205,1,0  ** surface Downward long wave flux [W/m^2]
DPTprs 25 17,100,0 ** (profile) Dew point temp. [K]
DPT2m  0 17,105,2 ** 2 m above ground Dew point temp. [K]
DSWRFsfc  0 204,1,0  ** surface Downward short wave flux [W/m^2]
ELONsfc  0 177,1,0  ** surface East longitude (0-360) [deg]
GFLUXsfc  0 155,1,0  ** surface Ground heat flux [W/m^2]
GUSTsfc  0 180,1,0  ** surface Surface wind gust [m/s]
HCDChcl  0 75,234,0 ** high cloud level High level cloud cover [%]
HGTsfc  0 7,1,0  ** surface Geopotential height [gpm]
HGTprs 25 7,100,0 ** (profile) Geopotential height [gpm]
HGT0deg  0 7,4,0 ** 0C isotherm level Geopotential height [gpm]
HGTadcl  0 7,5,0 ** adiabatic lifting condensation level Geopotential height [gpm]
HINDEXsfc  0 250,1,0  ** surface Haines index []
HLCY0_3000m   0 190,106,7680 ** 0-3000 m above ground Storm relative helicity [m^2/s^2]
HPBLsfc  0 221,1,0  ** surface Planetary boundary layer height [m]
LANDsfc  0 81,1,0  ** surface Land cover (land=1;sea=0) [fraction]
LCDClcl  0 73,214,0 ** low cloud level Low level cloud cover [%]
LFTX500_1000mb  0 131,101,12900 ** 500-1000 mb Surface lifted index [K]
LTNGsfc  0 187,1,0  ** surface Lightning [non-dim]
MCDCmcl  0 74,224,0 ** mid-cloud level Mid level cloud cover [%]
MSLETmsl  0 130,102,0 ** mean-sea level Mean sea level pressure (ETA model) [Pa]
MSLMAmsl  0 129,102,0 ** mean-sea level Mean sea level pressure (MAPS) [Pa]
NCPCPsfc  0 62,1,0  ** surface Large scale precipitation [kg/m^2]
NLATsfc  0 176,1,0  ** surface Latitude (-90 to +90) [deg]
PLI30_0mb  0 24,116,7680 ** 30-0 mb above gnd Parcel lifted index (to 500 hPa) [K]
PRATEsfc  0 59,1,0  ** surface Precipitation rate [kg/m^2/s]
PWAT30_0mb  0 54,116,7680 ** 30-0 mb above gnd Precipitable water [kg/m^2]
PWATclm  0 54,200,0 ** atmos column Precipitable water [kg/m^2]
REFCclm  0 212,200,0 ** atmos column Maximum/Composite radar reflectivity [dbZ]
RHprs 25 52,100,0 ** (profile) Relative humidity [%]
RH2m  0 52,105,2 ** 2 m above ground Relative humidity [%]
RWMRhlev1  0 170,109,1 ** hybrid level 1 Rain water mixing ratio [kg/kg]
SNMRhlev1  0 171,109,1 ** hybrid level 1 Snow mixing ratio [kg/kg]
SNODsfc  0 66,1,0  ** surface Snow depth [m]
SNOLsfc  0 79,1,0  ** surface Large scale snow [kg/m^2]
SNOMsfc  0 99,1,0  ** surface Snow melt [kg/m^2]
SNOWCsfc  0 238,1,0  ** surface Snow cover [%]
SSRUNsfc  0 235,1,0  ** surface Storm surface runoff [kg/m^2]
SUNSDsfc  0 191,1,0  ** surface Sunshine duration [s]
TCDCclm  0 71,200,0 ** atmos column Total cloud cover [%]
TMPsfc  0 11,1,0  ** surface Temp. [K]
TMPprs 25 11,100,0 ** (profile) Temp. [K]
TMP100m  0 11,105,100 ** 100 m above ground Temp. [K]
TMP2m  0 11,105,2 ** 2 m above ground Temp. [K]
UGRDprs 25 33,100,0 ** (profile) u wind [m/s]
UGRD305m  0 33,105,305 ** 305 m above ground u wind [m/s]
UGRD100m  0 33,105,100 ** 100 m above ground u wind [m/s]
UGRD80m  0 33,105,80 ** 80 m above ground u wind [m/s]
UGRD50m  0 33,105,50 ** 50 m above ground u wind [m/s]
UGRD30m  0 33,105,30 ** 30 m above ground u wind [m/s]
UGRD10m  0 33,105,10 ** 10 m above ground u wind [m/s]
ULWRFsfc  0 212,1,0  ** surface Upward long wave flux [W/m^2]
USWRFsfc  0 211,1,0  ** surface Upward short wave flux [W/m^2]
VGRDprs 25 34,100,0 ** (profile) v wind [m/s]
VGRD305m  0 34,105,305 ** 305 m above ground v wind [m/s]
VGRD100m  0 34,105,100 ** 100 m above ground v wind [m/s]
VGRD80m  0 34,105,80 ** 80 m above ground v wind [m/s]
VGRD50m  0 34,105,50 ** 50 m above ground v wind [m/s]
VGRD30m  0 34,105,30 ** 30 m above ground v wind [m/s]
VGRD10m  0 34,105,10 ** 10 m above ground v wind [m/s]
VISsfc  0 20,1,0  ** surface Visibility [m]
VISclt  0 20,3,0 ** cloud top Visibility [m]
VVELprs 25 39,100,0 ** (profile) Pressure vertical velocity [Pa/s]
WEASDsfc  0 65,1,0  ** surface Accum. snow [kg/m^2]
WTMPsfc  0 80,1,0  ** surface Water temp. [K]
ENDVARS

 There were a few complexities:

1. The first five variables listed (commented out in my descriptor) are missing the forecast interval metadata and so appear to be valid at the base time (00z17nov) in both the 20- and 30-minute data files. If these variables are important to you, you will have to jump through some extra hoops. For the moment, I will assume we can ignore them.

2. Your grib1 files have two different syntaxes for expressing the forecast interval -- for the 20-minute data file the unit is minutes and the interval value is 20; for the 30-minute data file the unit is 30 minutes and the interval value is 1. This is unusual (and confusing), but GrADS (and gribmap in particular) can deal with it. My descriptor specifies the base time in the TDEF entry as the same base time in the data files, so there will be no data for t=1 and t=2, which have forecast interval values of 0 and 10 minutes respectively. The 20-minute file is valid at t=3, and the 30-minute file is valid at t=4. You could also have used

chsub 1 1 WRFPRS_d01.00_20
chsub 2 2 WRFPRS_d01.00_30
tdef 2 linear 00:20Z17nov2017 10mn

But I find it is more intuitive to have the t=1 value be the start of a forecast. Either way will work.

—Jennifer

On Nov 21, 2017, at 3:47 PM, Wesley Ebisuzaki - NOAA Federal <wesley.ebisuzaki at noaa.gov<mailto:wesley.ebisuzaki at noaa.gov>> wrote:

Ivan,

New plan: don't fix g2ctl and alt_g2ctl.

Turns out that the problem was in your grib1 files.  Your grib1
20 minute forecast file had items like "20min fcst" and "valid 0-0min".
The last one should have been "valid 10-20min" or "valid 0-20min".
This error makes templating impossible.

Wesley

On Tue, Nov 21, 2017 at 2:42 PM, Wesley Ebisuzaki - NOAA Federal <wesley.ebisuzaki at noaa.gov<mailto:wesley.ebisuzaki at noaa.gov>> wrote:
Ivan,

The error message, "add_time: undefined time unit 14", comes from wgrib2.
So you have to be processing the grib2 files.

I don't work with files that are sub-hourly.  So the support for
minutes is not robust.  There is no support for minutes by
the program grib2ctl.pl.  G2ctl has some support for minutes
but it appears to be broken for your files.

Plan: fix g2ctl and alt_g2ctl. I stopped working
on grib1 utilities about 10 years ago.

Wesley

On Tue, Nov 21, 2017 at 1:20 PM, Ivan Toman <ivtoman at inet.hr> wrote:
Wesley,

Thank you very much for your efforts to help. However I'm still not sure we understand each other well? It is not important to me to use grib2 format. I just want to be

able to get data from model using GrADS, regardless of format or tools used. But I can't postprocess grib1 also, if I use grib2ctl.pl on grib1 format, I again get same error like when I use g2ctl on grib2, as I pasted below.

So basically for me neither grib2 nor grib1 work.

Ivan

On 11/21/2017 04:48 PM, Wesley Ebisuzaki - NOAA Federal wrote:
Ivan,

I just modified grb1to2.pl to add support for minutes time units.  Both
g2ctl and alt_g2ctl need some changes to add support for templates
that use minutes and forecast minutes.  I'll get to it soon.

The problem is that you are using cnvgrib to convert from grib1
to grib2.  Cnvgrib does not handle grib1 files that use a 30-minute
time units (value=14) and produces invalid grib2 files.

I talked with the person who use to support cnvgrib and he stated that
another person complained about a similar problem and that cnvgrib
is no longer supported.  So you are not going to get the fix from
the official source of the program.  The fix is straight forward;
however, you should reconsider how you do your processing.

Wesley

On Mon, Nov 20, 2017 at 6:47 PM, Ivan Toman <ivtoman at inet.hr> wrote:
Thank you Wesley,

but it seems that same problem happens with grib1 format, directly from UPP postprocessor:

grib2ctl.pl
 -verf WRFPRS_d01.00_30 >30.ctl
add_time: undefined time unit 14
PDS_date: problem
add_time: undefined time unit 14
PDS_date: problem

wgrib WRFPRS_d01.00_20
1:0:d=17111700:RWMR:kpds5=170:
kpds6=109:kpds7=1:TR=10:P1=0:P
2=20:TimeU=0:hybrid lev 1:20min fcst:NAve=0
2:44496:d=17111700:SNMR:kpds5=
171:kpds6=109:kpds7=1:TR=10:P1
=0:P2=20:TimeU=0:hybrid lev 1:20min fcst:NAve=0
3:88992:d=17111700:REFC:kpds5=
212:kpds6=200:kpds7=0:TR=10:P1
=0:P2=20:TimeU=0:atmos col:20min fcst:NAve=0

But:

wgrib WRFPRS_d01.00_30
1:0:d=17111700:RWMR:kpds5=170:
kpds6=109:kpds7=1:TR=10:P1=0:P
2=1:TimeU=14:hybrid lev 1:30min fcst:NAve=0
2:44496:d=17111700:SNMR:kpds5=
171:kpds6=109:kpds7=1:TR=10:P1
=0:P2=1:TimeU=14:hybrid lev 1:30min fcst:NAve=0
3:88992:d=17111700:REFC:kpds5=
212:kpds6=200:kpds7=0:TR=10:P1
=0:P2=1:TimeU=14:atmos col:30min fcst:NAve=0

I believe, pretty much the same response on time units on grib1 format.

Is this expected behaviour or grib files look wrong? I uploaded them here if you want to take a look:
http://gamma.meteoadriatic.net/tmp/jennifer/

Thx
Ivan

On 11/20/2017 01:52 AM, Wesley Ebisuzaki - NOAA Federal wrote:
Ivan,

Back from a conference.  14 = 1/2 hour for grib1. However
there isn't a 1/2 hour time unit for grib2.

   http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-4.shtml

The code needs to be changed to use minutes as the grib2 time units.
Note: grib1 only used 1 byte  or 2 bytes to store the forecast length.
Therefore they invented a large number of time units.  Grib2 uses
4 bytes to store the number of time units.

You can try to convince NCO to fix cnvgrib.  I know the person
responsible for cnvgrib and good luck.

My suggestion #1 doesn't work

$ wgrib2 wrfprs_d01.00_30.g2 -if ":30 min fcst:" -set_ftime "30 min fcst" -fi -grib wrfprs_d01.00_30.g2.con
add_time: undefined time unit 14
add_time: undefined time unit 14
add_time: undefined time unit 14

-if ":30 min fcst:" will always fail because wgrib2 doesn't understand the time code 14.
The error message "add_time: undefined time unit 14" comes from the calculation of
the verification time.

Wesley

On Fri, Nov 17, 2017 at 3:34 AM, Ivan Toman <ivtoman at inet.hr> wrote:
Wesley,

I think this comes from here:

On grib1 output from UPP - this is for 10min record, all normal:

$ wgrib WRFPRS_d01.00_10
1:0:d=17111700:RWMR:kpds5=170:kpds6=109:kpds7=1:TR=10:P1=0:P2=10:TimeU=0:hybrid lev 1:10min fcst:NAve=0
2:44496:d=17111700:SNMR:kpds5=171:kpds6=109:kpds7=1:TR=10:P1=0:P2=10:TimeU=0:hybrid lev 1:10min fcst:NAve=0
3:88992:d=17111700:REFC:kpds5=212:kpds6=200:kpds7=0:TR=10:P1=0:P2=10:TimeU=0:atmos col:10min fcst:NAve=0
...

however, for 30min record:

$ wgrib WRFPRS_d01.00_30
1:0:d=17111700:RWMR:kpds5=170:kpds6=109:kpds7=1:TR=10:P1=0:P2=1:TimeU=14:hybrid lev 1:30min fcst:NAve=0
2:44496:d=17111700:SNMR:kpds5=171:kpds6=109:kpds7=1:TR=10:P1=0:P2=1:TimeU=14:hybrid lev 1:30min fcst:NAve=0
3:88992:d=17111700:REFC:kpds5=212:kpds6=200:kpds7=0:TR=10:P1=0:P2=1:TimeU=14:atmos col:30min fcst:NAve=0
...

TimeU=14

Where this comes from?

As far as I understand it, UPP follows this time designation for time units:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table4.html
14 = "Half an hour"

This is from UPP code that sets it:

!    J. HALLEY GOTWAY, MODIFY HOW THE TIME INFORMATION IS STORED IN ID(17-20),
!    (FCST TIME UNIT, P1, P2, TIME RANGE INDICATOR).
!    CHECK IF THE NUMBER OF FORECAST MINUTES IS ZERO FOR HOURS OR NON-ZERO FOR
!    OFF-HOUR FORECASTS.  FOR OFF-HOUR FORECASTS, CHECK IF THE TOTAL NUMBER
!    OF MINUTES IS DIVISIBLE BY 30, 15, OR NEITHER, AND USE THE APPROPRIATE
!    FCST TIME UNIT VALUE.  FOR ANY FIELD OTHER THAN AN INSTANTANEOUS FIELD,
!    ASSUME ID(18-20), ARE PASSED IN CORRECTLY.

     IF(IFMIN .GE. 1)THEN
!       ID(17)     = 0
!    COMPUTE THE TOTAL FORECAST MINUTES.
       TOTMIN=IFHR*60+IFMIN

!    CHECK FOR 1/2 HOURLY INCREMENTS.
            IF (MOD(TOTMIN, 30) == 0) THEN
               ID(17) = 14
               DIV    = 30
!    CHECK FOR 1/4 HOURLY INCREMENTS.
            ELSEIF (MOD(TOTMIN, 15) == 0) THEN
               ID(17) = 13
               DIV    = 15
!    OTHERWISE, USE MINUTES.
            ELSE
               ID(17) = 0
               DIV    = 1
            ENDIF

Does this look OK to you?

Thx
Ivan

On 11/15/2017 02:39 PM, Wesley Ebisuzaki - NOAA Federal wrote:
Ivan,

I am not aware of a time unit 14.  It's not in NCEP's documentation.

Wesley

http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-4.shtml

On Wed, Nov 15, 2017 at 4:27 AM, Ivan Toman <ivtoman at inet.hr> wrote:
Wesley,

I finally found time to dig into this.

I actually get "undefined time unit 14" from wgrib2 when trying to handle 30 min records. That's probably why g2ctl, alt_g2ctl also does not do the job (throwing this message) and so on.

For example, your suggestion #2:

$ wgrib2 wrfprs_d01.00_30.g2 -if ":30 min fcst:" -set_ftime "30 min fcst" -fi -grib wrfprs_d01.00_30.g2.con
add_time: undefined time unit 14
add_time: undefined time unit 14
add_time: undefined time unit 14
1:0:d=2017111500:RWMR:1 hybrid level:1 ? fcst:
add_time: undefined time unit 14
add_time: undefined time unit 14
add_time: undefined time unit 14
2:2310:d=2017111500:SNMR:1 hybrid level:1 ? fcst:
add_time: undefined time unit 14
...

Or...

$ alt_gmp -i wrfprs_d01.grib2.ctl
wgrib2_flags=-npts -set_ext_name 1 -end_FT -ext_name -lev
wgrib2_inv=.invd01
dtype:  dtype grib2
pdef:  pdef 149 149 lccr -29.363000 45.203000 1 1 -21.633000 -21.633000 54.288000 12000.000000 12000.000000tdef:  nt=7 start=00Z15nov2017 by=10mn
zdef: nlevel=25
resolve_dsets dset=wrfprs_d01.grib2 inctime=10mn
resolve_dsets: no template
scanning wrfprs_d01.grib2 (process=0)
add_time: undefined time unit 14
add_time: undefined time unit 14
add_time: undefined time unit 14
add_time: undefined time unit 14
add_time: undefined time unit 14

grib1to2.pl did not work either, it failed:

$ for i in WRFPRS_d01.0* ; do ./grb1to2.pl -o $i.g2 $i ; done
(((rec 1:0:date 2017111500 RWMR kpds5=170 kpds6=109 kpds7=1 levels=(0,1) grid=255 hybrid lev 1 anl:
  RWMR=Rain water mixing ratio [kg/kg]
  timerange 0 P1 0 P2 0 TimeU 1  nx 149 ny 149 GDS grid 3 num_in_ave 0 missing 0
  center 7 subcenter 0 process 125 Table 2 scan: WE:SN winds(grid)
  Lambert Conf: Lat1 -29.363000 Lon1 45.203000 Lov 54.288000
      Latin1 -21.633000 Latin2 -21.633000 LatSP -90.000000 LonSP 0.000000
      South Pole (149 x 149) Dx 12.000000 Dy 12.000000 scan 64 mode 136
  min/max data 0 0  num bits 0  BDS_Ref 0  DecScale 0 BinScale 0

)))
>> grib2_metadata --- WRFPRS_d01.00_00   wgrib=./wgrib wgrib2=./wgrib2
Use of uninitialized value $1 in negation (-) at ./grib1to2_metadata.pl line 74, <INV> line 1.
no scan mode at ./grib1to2_metadata.pl line 83, <INV> line 1.
missing GRIB record(s)
((()))
Problem, winds not defined! old ./wgrib?
grib2 message ignored (use wgrib2)
missing GRIB record(s)
((()))
Problem, winds not defined! old ./wgrib?
(((rec 1:0:date 2017111500 RWMR kpds5=170 kpds6=109 kpds7=1 levels=(0,1) grid=255 hybrid lev 1 10min fcst:
  RWMR=Rain water mixing ratio [kg/kg]
  timerange 10 P1 0 P2 10 TimeU 0  nx 149 ny 149 GDS grid 3 num_in_ave 0 missing 0
  center 7 subcenter 0 process 125 Table 2 scan: WE:SN winds(grid)
  Lambert Conf: Lat1 -29.363000 Lon1 45.203000 Lov 54.288000
      Latin1 -21.633000 Latin2 -21.633000 LatSP -90.000000 LonSP 0.000000
      South Pole (149 x 149) Dx 12.000000 Dy 12.000000 scan 64 mode 136
  min/max data 0 5.31824e-06  num bits 16  BDS_Ref 0  DecScale 11 BinScale 4

I have no idea how to proceed further.
Tks,
Ivan

On 11/07/2017 08:12 PM, Wesley Ebisuzaki - NOAA Federal wrote:
Ivan,

"UPP follows NCEP code table for timing grib records - for 15 and 30
minute records use codes 13 and 14 respectively instead of simple
minutes. This seems to confuse GrADS (or g2ctl/gribmap, I'm not sure)."

"Yes it is fixed. I'm currently need to output 10 min intervals. So, for
full hour, 10m, 20m, 40m and 50m I get OK data. But for 30m I do not."

These quotes suggests that it is a problem with gribmap expecting
30 minute_time_units  and not being able to handle 1 30_minute_time_units.

Suggestion #1

    use alt_g2ctl/alt_gmp

    Both are based on wgrib2 which uses english rather than code table numbers.

Suggestion #2

    convert forecast time from 1 (30 minutes) to 30 (minutes)

     wgrib2 IN.grb -if ":30 min fcst:" -set_ftime "30 min fcst" -fi -grib OUT.grb

Wesley

On Tue, Nov 7, 2017 at 1:21 PM, Jeff Duda <jeffduda319 at gmail.com> wrote:
What result do you get when you do

wgrib2 -T (grib file)

?

Look after the "D=", as the represents the time in the GRIB2 file.

Jeff

On Tue, Nov 7, 2017 at 12:10 PM, Ivan Toman <ivtoman at inet.hr> wrote:
Hello,

Yes it is fixed. I'm currently need to output 10 min intervals. So, for full hour, 10m, 20m, 40m and 50m I get OK data. But for 30m I do not.

Thank you!
Ivan

On 11/07/2017 05:50 PM, Jeff Duda wrote:
What is your time interval? If it's not fixed, that's one problem. If it is fixed, then I don't see why regular templating wouldn't work unless the time being written to the grib2 file is not right. But there are ways to fix that.

Jeff Duda

On Tue, Nov 7, 2017 at 10:12 AM, Ivan Toman <ivtoman at inet.hr> wrote:
Hello,

I'm having difficulties reading sub-hourly time records from WRF grib
files in GrADS.

UPP follows NCEP code table for timing grib records - for 15 and 30
minute records use codes 13 and 14 respectively instead of simple
minutes. This seems to confuse GrADS (or g2ctl/gribmap, I'm not sure).

What I get as result is that I can read any sub-hourly record as long as
it is not 15 or 30 minute record. For those, I get undefined grid
instead of data.

I use this workflow for postprocessing: wfrout >(UPP)> grib1 >(cnvgrib)>
grib2 >(g2ctl,gribmap)> GrADS

Does anybody know what is going on there?

Thank you in advance

Ivan Toman

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

______________________________
_________________
gradsusr mailing list

gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

______________________________
_________________
gradsusr mailing list

gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

______________________________
_________________
gradsusr mailing list

gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

______________________________
_________________
gradsusr mailing list

gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

______________________________
_________________
gradsusr mailing list

gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr

--
Jennifer Miletta Adams
Center for Ocean-Land-Atmosphere Studies (COLA)
George Mason University

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20171122/7fd59743/attachment-0001.html 