Hi Bob et al: Im reviewing the situation with FIM GRIB tables. The table you sent (attached) has multiple entries for the same iparm. Its not clear how to map these to either GRIB-1 or GRIB-2. Perhaps you can get us correct mappings, for example in the format WMO or NCEP publishes their GRIB-2 tables. For now, I am disabling any FIM support in the CDM. John > > FIM is farther away from operational implementation at NCEP, and hasn't had > much outside scrutiny until now. (And, FIM scrutiny will really be ramping > up this year, as there is a new, large activity in GSD involving FIM.) > Also, FIM postprocessing generates GRIB1 natively. A separate step uses > NCEP's 'cnvgrib' to produce GRIB2 from the GRIB1. Ultimately, I'm hoping > that they will be able to carve out some resources to change over to > creating GRIB2 directly. But, that's not on the immediate horizon. So, the > GRIB1 gribtable file that I provided is all that I am aware of for FIM. > Conversions to GRIB2 parameters are built into the 'cnvgrib' package. > > I do think your last statement about using NCEP tables as a backup for FSL > is generally valid... or at least should be the case. In speaking with > modelers, they naturally treat GRIB tables as an afterthought relative to > actually generating decent model results. On the other hand, they are also > usually amenable to employing best practices if they know what they are. > > So, if you have any recommendations for what we should be doing differently > or better, please let us know. > > -Bob Ticket Details =================== Ticket ID: KCM-168963 Department: Support THREDDS Priority: Critical Status: Closed
Attachment:
fim_gribtable
Description: Binary data