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
