NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Daryl, My entry is similar to that, but I am writing all forecast hours to one file (since it is a smaller subset of the GFS (obtained using NCEP's grib filter) so I have something like: GFS $MODEL/gfs_swed_wx YYYYMMDDHH_gfs025.gem In looking at the datatype.tbl entry, as long as the name in nsharp_models.tbl matches what is in datatype.tbl so it finds the file (which it does) the geographic extent of the file should not matter, as I said the Browse function lets you find any model dataset on your disk and display it, so really NSHARP doesn't care about datatype.tbl, that is just for convenience. In my case, browsing to the file still had the same behavior. I have had weird issue like this with NSHARP in years past, so I suspect it may be a bug in NSHARP. Thanks, Robert -----Original Message----- From: Herzmann, Daryl E [AGRON] <akrherz@xxxxxxxxxxx> Sent: Friday, January 7, 2022 11:55 AM To: Mullenax, Robert R. (WFF-820.0)[ORBITAL SCIENCES CORPORATION] <robert.r.mullenax@xxxxxxxx>; gembud@xxxxxxxxxxxxxxxx Subject: Re: [EXTERNAL] Re: NSHARP issues GEMPAK 7.14 Hi Robert, Sorry for the delayed response here. I think a related issue is that I should not have taken the $GEMTBL/config/datatype.tbl as verbatim as I did when I updated to 7.14. Anyway, are you able to see what the previous entry within GEMPAK 7.5 was for your installation? Perhaps something like this? GFS $MODEL/gfs0.25deg YYYYMMDDHHfFFF_gfs.gem How is your global GFS gempak file named within the $MODEL folder? daryl ________________________________________ From: Mullenax, Robert R. (WFF-820.0)[ORBITAL SCIENCES CORPORATION] <robert.r.mullenax@xxxxxxxx> Sent: Wednesday, December 22, 2021 12:15 PM To: Herzmann, Daryl E [AGRON]; gembud@xxxxxxxxxxxxxxxx Subject: RE: [EXTERNAL] Re: NSHARP issues GEMPAK 7.14 Hi Daryl, It is the 0.50 degree grid I used for a test case. The $GEMTBL/nsharp/nsharp_models.tbl file has the model name and it gets the name from datatype.tbl. I had "GFS" pointed to the 0.5 degree grid. I am not sure why it would care as long as it finds the file, because one can you use the Browse option and in theory go to any grid and view it. However what you say does make it seem like it is tied to a CONUS like grid. In GEMPAK 7.5, it works fine. Thanks, Robert Mullenax -----Original Message----- From: Herzmann, Daryl E [AGRON] <akrherz@xxxxxxxxxxx> Sent: Wednesday, December 22, 2021 12:09 PM To: gembud@xxxxxxxxxxxxxxxx; Mullenax, Robert R. (WFF-820.0)[ORBITAL SCIENCES CORPORATION] <robert.r.mullenax@xxxxxxxx> Subject: [EXTERNAL] Re: NSHARP issues GEMPAK 7.14 Greetings, That sounds like it is confused by which GFS grid it is looking at. Which GFS gempak grid numbers do you locally have available to GEMPAK for usage? I am unsure how nsharp translates the "GFS" grid label into a file. daryl ________________________________________ From: gembud <gembud-bounces@xxxxxxxxxxxxxxxx> on behalf of Mullenax, Robert R. (WFF-820.0)[ORBITAL SCIENCES CORPORATION] via gembud <gembud@xxxxxxxxxxxxxxxx> Sent: Wednesday, December 22, 2021 8:32 AM To: gembud@xxxxxxxxxxxxxxxx Subject: [gembud] NSHARP issues GEMPAK 7.14 Good morning, Thanks so much to Daryl for providing a GEMPAK 7.14 version that will build on Red Hat 8.x. Functionality seems to be good so far, except for NSHARP. Despite having a GFS file that is complete (all levels, params, and global) NSHARP will only display soundings from about 15N to 60N and 60W to 140W. I have verified that data exists outside those regions. This really has me stumped, and I don't see any errors it just won't display a plot. Thanks, Robert Mullenax Robert Mullenax Meteorologist CSBF/Peraton Columbia Scientific Balloon Facility robert.r.mullenax@xxxxxxxx<mailto:robert.r.mullenax@xxxxxxxx> 903-729-0271
gembud
archives: