[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GEMPAK #RGI-969779]: Gempak Decoders
- Subject: [GEMPAK #RGI-969779]: Gempak Decoders
- Date: Mon, 23 Jun 2014 10:29:44 -0600
> Hi Michael, I have contacted the brazilian navy in order to know the source
> of the Cosmo GRIB file.
> They said that the navy has contacted Unidata thru the Capitão-Tenente
> Flávia some time ago. She has talked with "Michel" James from Unidata. They
> have discussed this format widely and he said to her that the Cosmo GRIB
> file would be supported by Gempak 6.10.
>
> Are you the "Michel" James?
Haha, yes that is me. In 6.10, the grib decoder "dcgrib2" was updated to
support these Cosmo grids, that is why an update to current version 7 was
needed for the GEMPAK grids to be created correctly on your machine. As to
what is or should be in the file, that is determined by the organization which
creates the grib messages. With grib decoding, GEMPAK must have the correct
grib tables present to match the fields in the grib messages. If a model has a
special data set and uses non-standard fields, GEMPAK must be supplied with
special grib tables to "override" the standard WMO tables. If the data in the
original grib message use standard parameter values (they should!) then what
you see in the GEMPAK grid is what you see in the grib message.
Just to be clear, the Cosmo grib message are being decoded to GEMPAK grid files
on your machine, and the last error that you had with GDPLOT3 is due to
requesting fields from the grid file which do not exist (like 500mb
temperature). If you use GDINFO to choose a grid known to exist in the file,
and use those values in GDPLOT3, you will see the Cosmo data drawn to the
screen.
Michael James
Unidata
Ticket Details
===================
Ticket ID: RGI-969779
Department: Support GEMPAK
Priority: Normal
Status: Open