[GEMPAK #UMM-268494]: Help decoding ABOM ACCESS Model data

Using the file IDY25200.pres.msl.2010122906.003.surface.grb for this example, 
with wgrib I see the originating center ID is 1 so I added the following line 
to cntrgrib1.tbl


001 ACCESS                                                           ACSS


I renamed grib128.tbl to acssgrib128.tbl and copied it to $GEMTBL/grid/

I then had to reformat acssgrib128.tbl following the column format of other 
grib tables (see wmogrib128.tbl); the provided grib tables are formatted as 

ID | GNAM | UNITS | NAME

when they should be in the order

ID | NAME | UNITS |GNAM | SCALE | MISSING | HZREMAP | DIRECTION 


An example of this for MSLP (ID 151) is 

!
! ACSSGRIB128.TBL -- GRIB 1 parameter conversion table version 128
!
!ID# NAME                             UNITS                GNAM         SCALE   
MISSING HZREMAP DIRECTION
!
151 mean sea level pressure           Pa                   MSLP             0  
-9999.00       0         0



If you run dcgrib2 at this point the PDS EXT STRING (C009) will be appended to 
the end of the parameter name (so GPARM = MSLPC009), so you have to provide the 
option -e ENSEXT=0 

( full command: dcgrib2 -e ENSEXT=0 pres.gem < 
IDY25200.pres.msl.2010122906.003.surface.grb) 

so the PDS EXT parameter name extensions are not appended. 

With this I was able to decode the MSLP grid (from GDINFO):


 GRID NAVIGATION: 
     PROJECTION:          CED                 
     GRID SIZE:          680 544
     LL CORNER:             -55.00     95.00
     UR CORNER:               4.73    169.69

 GRID ANALYSIS BLOCK: 
      UNKNOWN ANALYSIS TYPE 

 Number of grids in file:     1

 Maximum number of grids in file:   5000

  NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
    1     101229/0600F003                          0         NONE MSLP    



The step that should have you on your way is simply the renaming and 
reformatting of grib128.tbl. 


Michael James
Unidata






> Sure, I wasn't trying to rush you, it's just that I understand it's the 
> holidays and everything, and certainly understand if it will be a few days.
> 
> Thanks,
> Robert
> 
> 
> 
> -----Original Message-----
> From: Unidata GEMPAK Support [mailto:address@hidden]
> Sent: Thu 12/30/2010 12:47 PM
> To: Robert Mullenax
> Subject: [GEMPAK #UMM-268494]: Help decoding ABOM ACCESS Model data
> 
> Hi Robert,
> 
> I'm working on it this morning, but having no experience with these types of 
> files I'm learning as I go.  I will update you on this ticket in a few hours 
> if I have a solution for you or not.  Sound good?
> 
> Best,
> 
> Michael
> 
> >
> > Since I have about 10 things going on at this time.  I would appreciate an 
> > estimate of when someone might be able to get back to me on this.  if it is 
> > going to be say, late next week, I will put this project (this is just one 
> > part of it) on the backburner and move on.
> >
> >
> 
> Ticket Details
> ===================
> Ticket ID: UMM-268494
> Department: Support GEMPAK
> Priority: Normal
> Status: Open
> 
> 
> 
> 


Ticket Details
===================
Ticket ID: UMM-268494
Department: Support GEMPAK
Priority: Normal
Status: Open