This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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