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

20000719: Processing surface data



Chris,

Its possible that the surface file actually doesn't contain any 15Z observations
if the data stream to your LDM is showing some latency around that time-
eg, if your latency is up to an hour, then you may not have received any 
metar products by 35 after the hour.

I tried to check your latency, but it appears that your LDM isn't sending
any stats. You probably should checkinto that.

As for the GEMPAK ananlysis, if you know that you have received metars for
15Z when OABSFC is run, then we can check into that.

I do have a program I can place in contrib that will list out the times in
a surface file, or alternately print out the time if it exists in the
file. That way, a script can tell if the 15Z surface obs are in the file.

The program is in ~gbuddy/nawips-5.4/contrib/sfctime.tar.Z

If you want to build this program, download into a clean directory-
eg make a directory such as $NAWIPS/unidata/programs/sfctime.
The unpack the contents of the tarfile in that directory.

You should be able to build with:
make all
make install
make clean

I have't updated the Makefile in a while, so if you have trouble, let me know.

Running the program can either dump the times in a file:

% sfctime $SAO/20000719_sao.gem
000719/0000     
000719/0020     
000719/0040     
000719/0100     
000719/0120     
000719/0140     
000719/0200     
000719/0220     
...

Or check to see if a certain time exists, 

% sfctime $SAO/20000719_sao.gem 000719/1500
000719/1500

If the time is returned, then it exists.
In a csh, this would look like:

set EXIST=`sfctime $SAO/20000719_sao.gem 000719/1500`
if($#EXIST > 0) then
   # time exists...do procesing
endif


Unfortunately, the program doesn't know any shorthand for the times
so you have to enter it as yymmdd/hhmm insteas of just 15 for example.

Steve Chiswell
Unidata User SUpport

>Organization: UCAR/Unidata
>Keywords: 200007191605.e6JG5BT09230

>Hello.
>
>I run OABSFC at about 32 minutes past every hour to process all of my
>current surface data maps.  But many times, my log files state that I have
>specified an invalid time:
>
>GEMPAK-OABSFC> [TI 2]  The time 000719/1500 is not found in the data set.
> [TI -2]  No valid times entered.
> [OABSFC -11]  Time cannot be found in 
>/usr/local/ldm/data/surface/20000719_sao.gem
>
>That was from my program which was invoked at 1535 UTC.  Other times,
>however, everything runs normally and I get a plethora of surface data.
>Is this a data receipt problem?  Other ideas?  My input to OABSFC looks
>like:
>
>oabsfc << EOF
> SFFILE   = ${SFFILE}
> GDFILE   = $HOME/grids/current_analy.grd
> SFPARM   = tmpf;dwpf;pmsl;p03c;sknt;p24i;snow;heat;vsby;wceq;uwnd;vwnd
> DATTIM   = ${hh}
> DTAAREA  =
> GUESS    =
> GAMMA    = 0.3
> SEARCH   = 20/EX
> NPASS    = 2
>r
>
>e
>EOF
>
>where hh = 15
>
>Thanks.
>
>Chris
>
>================================================
>| Chris Hennon        Ohio State University   |
>| Tropical Meteorology      address@hidden   |
|                                              |
>| Dept of Geography   Office: 1155 Derby Hall  |
>| 1036 Derby Hall     Phone : (614) 292-2704   |
>| Columbus, OH 43210  Fax   : (614) 292-6213   |
>================================================
>