Re: [gembud] Surface & upper air corruption?

• To: "Boothe, Mark (CIV)" <maboothe@xxxxxxx>, "gembud@xxxxxxxxxxxxxxxx" <gembud@xxxxxxxxxxxxxxxx>
• Subject: Re: [gembud] Surface & upper air corruption?
• From: "Mullenax, Robert R. (WFF-820.0)[ORBITAL SCIENCES CORPORATION]" <robert.r.mullenax@xxxxxxxx>
• Date: Wed, 30 Oct 2019 16:52:29 +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-SenderADCheck; bh=Lle3yHVReQu3Z2lXbziOwh1UN98nNB/16ALaD7iaLAA=; b=R9tzUAgrRNeKQ+Q/LV3CiOROkRq2LzVJhpbUyEovorPU8Q4o4QGWoeo+EoqGOReDCvqU7beigqIZxX97sPkx/V84sTF0W2g/E0ypa3sQJ3gtX8Tz9/iLyO/f/rtf6BO/SKorVwDipGmFaDs0IzRoGfmS+o2JOBPYS2HnEUTD+OMmZYTv+rd9NgyrL1oEHLtZ5AZJFJWwwszJ4nXdRtzmTKIzvqo4xWQvnwpnq9ox6GLP8s1mEMMSwSq9Iqs2K5vJwEIWppiZjc0EWJ8kIkPVJdwsmoCR8a81sp0LHlaPawUZc4T7jIYOktEsbU4pEuXWdTwSl8YK/qWtZYnJ3HK9Kw==
• Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J4kkjXYFc59EPZ6YDhLUzk4OXLomLY5nX6nVeA61TdHSn+MgGUp32+dSW/2PATjM11whWhwp5BDQSvf0iL+OYTDJ8zQ3wmzcZrtIZfxsklpdpZwKXN1HW3GKWh/zvdpfgpagGazZYdsLdPFu8lQ+ZRRCL+mShRAd7lKn36A+ii3DtKlgYwjyFioAzMNM92M6UyMi7HkZP1vj+EsauwhCDiSsarckZYKpFfRdOAvD+A0+opoDJEovWoAu/WuEC5r2LywkXQJtkOFKPhAtWF1zM4lxJvFzYBbNXAyQs6h5d+y3ymfl8kwo4b03aMJCDrt7ofJtQ6vuJLXzHvEmhnlkNQ==

Hi Mark,

I have never found a way to fix the file once it becomes corrupted. Unidata has 
current data available as a nice backup to replace the corrupted file (usually 
up, but of course it isn't considered operational):

https://motherlode.ucar.edu/decoded/gempak/surface/
https://motherlode.ucar.edu/decoded/gempak/upperair/

Also, have you tried opening surface/upper air in NMAP2 instead of GARP?  One 
reason Unidata stopped support of GARP was instability. In my experience, 
especially GARP built on Linux. It could be GARP is the problem.

Best regards,
Robert Mullenax



From: gembud <gembud-bounces@xxxxxxxxxxxxxxxx> On Behalf Of Boothe, Mark (CIV)
Sent: Wednesday, October 30, 2019 10: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)