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