Re: [gembud] [EXTERNAL] Re: NSHARP issues GEMPAK 7.14

  • To: "Herzmann, Daryl E [AGRON]" <akrherz@xxxxxxxxxxx>, "gembud@xxxxxxxxxxxxxxxx" <gembud@xxxxxxxxxxxxxxxx>
  • Subject: Re: [gembud] [EXTERNAL] Re: NSHARP issues GEMPAK 7.14
  • From: "Mullenax, Robert R. (WFF-820.0)[ORBITAL SCIENCES CORPORATION]" <robert.r.mullenax@xxxxxxxx>
  • Date: Tue, 18 Jan 2022 20:12:42 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nasa.gov; dmarc=pass action=none header.from=nasa.gov; dkim=pass header.d=nasa.gov; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lDqTQeYIRZiT2iMa0LztpJgWSHbQ616lIvRxczdBPvc=; b=D1PJujOB2ILPedzIM9ckgz6OPVJ6Rn4+ji7av5KB9e/LJWvtGQN6c+waXoJy6YLMy8XN/8I38CprnlFeXdVmni/DXEyJ5cI9EGBuqUZChY5wqrihCAo1BP7NJ0voYx58In0R4hcdb462DvZUORHz4UjKKhEtyap/5k6W4BJJ5cjE5iPBzJuIFECTa3K3FXSlKLIJcmg0jEaJT6nZtxSoW0dcJeI1ec5B2RrEDMfV5hQdw4HiwjemHEopPrVu2nA4aIReQmZ6Ag1UsqYB/1TCg1Fu4OtRRoFWq9IssrGX40R3gB+zeqlz+Nu58KdHCSn9hJUzrash6H//rvwdaJ8lmg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nthqXBHJ8+O/se83mUcvnGFC9D11Ko4qAzGdyevlsu3YmhjONjE8cElagjqXjSl1fDVOLKVS12a+b7GeiGA7nEC1FUCNM3INzRclWQRLhbvo15qwkOwZgJeKs/7vF1q0Dt3cJb1Yc/QXfvwWbg6+4Tkgs5LElD0elr2fo4MN1pZenXjYltNBrYJ1WahldvCTIFxa+s2Vj+jvGfpU5VlWYFnUrajOiayVT3ck1Imcz0Nm/F4oETNsm4Dk9pHV5vzUcboixTRpF5rSELZ6d5YJ7cO9bgsfsz5Yql6C0GAfL35BKBHWoLtydoRKE8Bod6LEZVuJ4T5voFr76zOgwVmUDg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nasa.gov;
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


  • 2022 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the gembud archives: