LATS4D

[Michael Fiorino]

hi lisa,

the problem is not lats4d.gs but the underlying "LATS" (.c) code the
does grib encoding.

i wrote the grib encoder and not all grib parameters can be set by the
LATS-grads interface (i wrote this too...), specifically the table #.
that is hardwired in latsgrib.c, so you'll have to work the source to
set or put in an interface.

according to latsgrib.c bytes 26-27 are being set to the number of
points equator to pole,

    dy=(int)(((gds->nj)/2));

and

if(gds->drt != 220) {
...
    set_int2(&gds->gds[25],(unsigned int)abs(gds->dy));
...

this happens when the grid is set as

var->grid->type == LATS_GAUSSIAN

in the lats-grads interface (in grads), you would have to say (in
gauser.c) :

'set lats gridtype gaussian'

grads will detect the number of points in x and y and encode the proper
number in octet 26-27.

bottom line: the grid should be encoded properly by latsgrib.c (in the
grib "GDS") if you set the gridtype, but the table number cannot.

hope this helps

/r mike



in the latscan be set without dealing directly with the lastsith ying
lats code.

Lisa Murphy wrote:
> Hello Grads users,
>
> I'm having issues with the lats4d.gs script.  I have a simulation from NCARs
> Community Atmosphere Model.   My files are netcdf and I'm trying to convert
> to GRIB.  I modified the lats4d.gs script so that it puts in the correct
> grib parameter values (idc), title, and units in the following statement,
> which is in lats4d.gs:
>
> record = name '| ' idc ' |' title ' | ' units ' | ' dattype ' | ' levtype '
> | ' scale_factor ' | ' precision
>
> I used values from the ncep parameter table found here:
> http://dss.ucar.edu/docs/formats/grib/gribdoc/
>
> and changed the ncar center information in the lats4d.gs script to have the
> following:
> process: 0
> center: 7
> subcenter: 1
>
> and I also used the option: -center ncar
> when invoking the lats4d script.
>
> rc=write(fname,'ncar      | 0  | 7 | 1',append)
>
> It looks like it is successful and I can open up the new grib file in GrADS
> and view all of the data.  However, if I try to open the file in NCL and
> look at the data it gives me a bunch of errors.  It tells me that there is
> an unknown grib parameter number:
>
> 1, center 7, table version 128 grib record 7), using default variable name
> (VAR_1)
>
> and,
> the Gaussian latitude coordinate array is partially or wholly undefined.
>
> The reason I'm posting here and not NCLs user board is because I think it's
> an error with the lats4d.gs script.  For example when I use the wgrib
> command to view the information in the file it gives me:
>
> rec 169:2751264:date 0002120106 HGT kpds5=7 kpds6=100 kpds7=4 levels=(0,4)
> grid=255 4 mb anl:
>   HGT=Geopotential height [gpm]
>   timerange 0 P1 0 P2 0 TimeU 1  nx 128 ny 64 GDS grid 4 num_in_ave 0 missing 0
>   center 7 subcenter 1 process 0 Table 128 scan: WE:NS winds(N/S)
>   gaussian: lat  -87.864000 to 87.864000
>             long 0.000000 to 357.188000 by 2.813000, (128 x 64) scan 2 mode
> 128 bdsgrid 1
>   min/max data 33488.4 38216.8  num bits 16  BDS_Ref 33488.4  DecScale 0
> BinScale -3
>
> How does the GrADS lats4d script specify the table number (in my case it
> sets it to 128) but according to NCARs grib website it looks like it should
> be either Table 3 or Table 180, and the grid number (in my case it sets it
> to 4).  My data is on a Gaussian T42 grid (128X64).
>
> So basically I'm just confused about how this script works and how it write
> the netCDF data to the new grib file.  NCL tells me:
> Invalid value for Gaussian LatLon grid in GDS octets 26-27;
> I know that
> 26-27 N - number of parallels between a pole and the equator
> but where do I specify this??
>
> Thank you for your time and any help you can provide!!!
>
> Lisa
>