Re: [gembud] [EXTERNAL] Surface & upper air corruption?

• To: "Boothe, Mark (CIV)" <maboothe@xxxxxxx>, "gembud@xxxxxxxxxxxxxxxx" <gembud@xxxxxxxxxxxxxxxx>
• Subject: Re: [gembud] [EXTERNAL] Surface & upper air corruption?
• From: "Herbster, Christopher G." <herbstec@xxxxxxxx>
• Date: Fri, 1 Nov 2019 17:37:55 +0000
• Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=erau.edu; dmarc=pass action=none header.from=erau.edu; dkim=pass header.d=erau.edu; 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-SenderADCheck; bh=qnFSosgdMztrFAWOjxpOLME26OZAUBaNfM4eDCBtirU=; b=Bhmy3k9nZJi/AwfTcy+3j2gZSUOod5knnYSFIj+3Gg2qFHGQvHtgFPQDwKwZEjV5rZWFEdRqnboAfDeuRTrlmFD+MpdiaIHgFHKGMU5T6ahZorPtZOxV6YBX4dtM+9Q0wOd8q0cXfhELcXfD6rG4W2BUTiU/G0HF+wJlzWsfIS75WAjZPwfXAtIB0Ko/t6vAjRkjOO3Gar49i9g9eOm6WM/hcMKBgHTXR5rFoQSsGWPg2wK2jKzBMuYqhPo+JRS+F0W8o0Nfb9wwxjSrRgrV5TbC7JWe/NW6WpMHCidt+6yYFHaQbp/T0znGSdOHSYXeCS4RdLE+5FukIr/npSu9dw==
• Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MKtsmsTb7b6b9Biwh2ijYM0Hgp1v3rBf9Y3Y4PJo/3Tg5+PpnRHvXazr66OyG5PTVzGkK4tptY10rnYYQBwMWbwy15SNxjMJrEzNDTM4SxEdibFXmzHSXSXpPRAWn8Zo8JXhgZ/zux9zydMRL0DkB8sdnGqONujVIIPeKaNCnteaxnOES7X8Du1BGofj0yoO/Czt/f9BdUTMbHSfqxjFrNKwaxJYth+nrwn2CT9WZ5dSl1qvpAplt7j8ruyANtYBSyXLydnV0GdgMbjNrmipX4vzrMlvlm9N3JdF9lN5zA0CzuqVWfIctdHYM625x1CxDgRkF3ROB+6sHFaBWSwIFg==
• Authentication-results: spf=none (sender IP is ) smtp.mailfrom=herbstec@xxxxxxxx;

Hi folks,

I would suggest that you test the file with a command line tool, like sflist, 
or similar.  We have found that GARP is prone to some hardwired limitations in 
the FORTRAN allocations for lengths of various arrays.  For example, when 
dual-pole radar became available, we had increase the number of parameters 
allowed in the menu building list for products (or some similar issue, it is 
all a bit of a blur now).  I think we hit a similar limit when the number of 
radar locations went beyond 128 as well.

It is possible that the number of observations (records) is more than GARP is 
coded to allow.  The limitation for SFLIST is governed from different 
parameters when GEMPAK is built, so it may not have the same limitations.

Just a friendly suggestion,

Chris

(lurk mode back on)

Dr. Christopher G. Herbster
Associate Professor
Director of Science and Technology
for the ERAU Weather Center
Applied Aviation Sciences
Embry-Riddle Aeronautical Univ.
1 Aerospace Blvd.
Daytona Beach, FL 32114-3900
386.226.6444 Office
386.226.6446 Weather Center
http://wx.erau.edu/

Schedule at:  http://wx.erau.edu/faculty/herbster/Schedules/

From: gembud <gembud-bounces@xxxxxxxxxxxxxxxx> On Behalf Of Boothe, Mark (CIV)
Sent: Wednesday, October 30, 2019 11:41 AM
To: gembud@xxxxxxxxxxxxxxxx
Cc: Yamaguchi, Ryan (CIV) <ryamaguc@xxxxxxx>; Nuss, Wendell (CIV) <nuss@xxxxxxx>
Subject: [EXTERNAL] [gembud] Surface & upper air corruption?

Hello Gembud list,

While our reception of satellite and model data are good here at NPS, GARP 
crashes upon request for surface or upper air observations. We've noticed this 
problem, intermittently for the last week or so.  If a particular day is 
unavailable, data for the following day, starting at 0000 UTC, can sometimes be 
fine, which seems to suggest that once a particular day's gempak file is 
"corrupted", it is completely corrupted for the entire day.

Does anyone know of a common cause of this problem?  If it is a problem caused 
by just a single bad datum point, is it possible to "surgically" remove the 
offending point from the .gem file? Is there a way to search the 'dcmetr.log' 
file to find the culprit? What would I usually search for? (Or am I barking up 
the wrong tree?)

Thanks in advance for any guidance,
Mark Boothe
Naval Postgraduate School

• References:
  • [gembud] Surface & upper air corruption?
    • From: Boothe, Mark (CIV)