[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010403: 20010402: getraob

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20010403: 20010402: getraob
  • Date: Tue, 03 Apr 2001 16:03:33 -0600
>From: address@hidden
>Organization: UCAR/Unidata
>Keywords: 200104032150.f33LoML16311

>Steve,
>       I decided to go ahead and run SNLIST on the next 30 stations I
>obtained.  fsltogem ran for a few minutes then gave me this error:
>
>saturn> fsltogem 1951090103.rao
>[24558] 010403/1442 [DC 3]  Starting up.
>error writing data for TUS 570122/2100 [-13]
>error writing data for TUS 570216/0900 [-13]
>error writing data for TUS 570312/2100 [-13]
>error writing data for TUS 570313/1500 [-13]
>error writing data for TUS 570402/2100 [-13]
>error writing data for TUS 570413/0300 [-13]
>exceeded maximum times in a gempak file
>
>
>The STRANGE thing is that Tuscon wasn't one of the 30 stations listed
>to be part of the new .rao file.  Not sure what's going on...
>
>Diana
>


Diana,

I compiled the GEMPAK version to allow 2000 times in a file.

Assuming up to 4 times per day x 365 would use 1460 times.
However, if 8 times (every 3 hours) were used, that would exceed
2000.

With one station in the file, you probably won't get near 2000. But,
with lots of stations at different times at each station, I can see
that being a problem. You could decode into mothly files, eg
YYYYMM instead of just yearly. 

As for TUS, you can see if the WMO number you specified was changed
to TUS in that year (like 72469 has been LWY, DEN, AKO, DNR
at different times in history). AKO is quite far away from Denver.

Steve Chiswell