[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #PFA-833229]: ETA initializations no longer showing F000



Pete,

This difference in the grib files posted at NCEP versus those posted on the
operational NWSTG server has a history where the bit is physically flipped
when it is sent to the operational systems due to their software (eg AWIPS)
expectations.

The model is actually run for 1 timestep, and then the data are output as the
model initial conditions at time 0. The GEMPAK gemlib/gb/gbftim.c routine
had beed written to match the TG modified gribs. I have modified this
routine in the 5.9.4 distribution which you can download from the server now
(source or binary). The dcgrib2 code will name either version of the NCEP or 
NWSTG
grids as F000, rather than the previous behavior of dropping the Ffff for the
"initialized analysis".

I thought that the 5.9.3 distribution would have the same problem you viewed in 
5.8.3 
(the F000 omitted since these are analyses and not forecasts).

Luckily, the GRIB2 grids do not have this problem.

Steve Chiswell
Unidata Use Support



> 
> Steve/whoever,
> 
> Ever since the CONDUIT change over to the new server, most of the eta
> grids on 212 and 104 at F000 are being decoded by dcgrib2 to not
> include an F000 in their dattim.
> 
> For example, a gempak file created from a 104 eta analysis from
> July shows the following for 500 hPa height:
> 
> NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
> 252     060724/1200F000                        500         PRES HGHT
> 
> whereas the same file from today shows:
> 
> NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
> 255     061102/1200                            500         PRES HGHT
> 
> Looking at the grib files, it looks like PDS octet #21 has changed from
> 0 to 1, meaning it is now identified as an initialized analysis, rather
> than an uninitialized analysis as before.
> 
> Is there any reason that dcgrib2 shouldn't put the F000 on there anyways?
> 
> We've got some scripts here that rely on F000 to be in there, and they
> are not finding the F000 analysis in the files now.
> 
> Some testing shows that if I convert to gempak with GEMPAK 5.9.3 and
> view with 5.9.3, requesting the time F000 finds the records, even
> though the F000 isn't displayed. Converting or viewing with 5.8.3 or
> earlier does not find F000 in the file.
> 
> Is the solution to this just to make sure I'm running at 5.9.3 for
> all the conversion to gempak and for all the plotting/listing?
> 
> Thanks,
> 
> Pete
> 
> 
> --
> +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
> ^ Pete Pokrandt                    V 1447  AOSS Bldg  1225 W Dayton St^
> ^ Systems Programmer               V Madison,         WI     53706    ^
> ^                                  V      address@hidden       ^
> ^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
> ^ University of Wisconsin-Madison  V       262-0166 (Fax)             ^
> +<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
> 
> 


Ticket Details
===================
Ticket ID: PFA-833229
Department: Support GEMPAK
Priority: Normal
Status: Closed