comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » IDL Grib Routines
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
IDL Grib Routines [message #85511] Wed, 14 August 2013 09:57 Go to next message
Chip Helms is currently offline  Chip Helms
Messages: 24
Registered: November 2012
Junior Member
Hi all,

I'm trying to read GFS model winds out of grib2 files using Mark Piper's helper routines and I've run into an issue. The record indices for the wind components are designated as floats with '.1' for UGRD and '.2' for VGRD. Since Mark Piper's grib helper routines assume that the index is an integer, they return UGRD data for both '.1' and '.2' indices. I'm curious if anyone else has run into this issue and if anyone knows a work around for it?

Here's an example of the wgrib2 inventory output for UGRD and VGRD variables as well as a variable that has an integer index for comparison:

109.1:18590308:d=2013081306:UGRD:850 mb:anl:
109.2:18590308:d=2013081306:VGRD:850 mb:anl:
110:19009437:d=2013081306:TMP:10 mb:anl:

The files I'm opening are the operational analysis (the same issue arises with the operation forecast files as well). Worst case scenario, I can convert the files to netcdf and then open them, but that is a rather time consuming process.

Thanks in advance,
Cheers,
Chip
Re: IDL Grib Routines [message #85513 is a reply to message #85511] Wed, 14 August 2013 10:22 Go to previous messageGo to next message
Fabzi is currently offline  Fabzi
Messages: 305
Registered: July 2010
Senior Member
Hi Chip,

On 08/14/2013 06:57 PM, Chip Helms wrote:
> Worst case scenario, I can convert the files to netcdf and then open
> them, but that is a rather time consuming process.

This is what we decided to do. NetCDF is in many ways easier than GRIB.
Several tools also propose a NCDF4 compression "on the fly" which is
more time consuming but on the long term actualy quite efficient since
you have to do it once and only once nd you spare disk space.

We use NCL for this, with the command:

ncl_convert2nc fnl_file.grib -cl 5 -nc4c
Re: IDL Grib Routines [message #85633 is a reply to message #85511] Thu, 22 August 2013 13:37 Go to previous message
Mark Piper is currently offline  Mark Piper
Messages: 198
Registered: December 2009
Senior Member
On Wednesday, August 14, 2013 10:57:03 AM UTC-6, Chip Helms wrote:
>
> I'm trying to read GFS model winds out of grib2 files using Mark Piper's helper routines and I've run into an issue. The record indices for the wind components are designated as floats with '.1' for UGRD and '.2' for VGRD. Since Mark Piper's grib helper routines assume that the index is an integer, they return UGRD data for both '.1' and '.2' indices. I'm curious if anyone else has run into this issue and if anyone knows a work around for it?
>

Hi Chip,

Setting the MULTI_SUPPORT keyword on GRIB_INVENTORY or GRIB_GET_RECORD should fix this. Here's wgrib2 output for a GFS file with multi-field records:

1:0:d=2012051012:HGT:10 mb:anl:
2:15679:d=2012051012:TMP:10 mb:anl:
3:22323:d=2012051012:RH:10 mb:anl:
4.1:23802:d=2012051012:UGRD:10 mb:anl:
4.2:23802:d=2012051012:VGRD:10 mb:anl:
5:48782:d=2012051012:ABSV:10 mb:anl:
...

To get the 10 mb V wind component, record 4.2, use 5 as the index:

IDL> f = 'gfs.t12z.pgrbf00.2p5deg.grib2'
IDL> r5 = grib_get_record(f, 5, /structure, /multi_support)
IDL> print, r5.parametername, r5.level
v-component of wind 10

Index 6 would then give the 10 mb absolute vorticity, etc.

I know this is a clumsy interface. I'll have to think about a better way to handle multi-field records. Do you (or anyone) have any suggestions?

mp
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: avoiding "floating illegal operand" errors with /nan keyword in mean
Next Topic: ticklen in NG plots

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 15:07:26 PDT 2025

Total time taken to generate the page: 0.00488 seconds