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

[GEMPAK #GUX-304848]: GEMPAK and GARP

Jennie,

>But when I run the scour utility, it doesn't do anything. This seems
>strange, since there are grids in this directory that cover 2006021518.....
>through 2006021612.... I guess I thought it would get rid of the February
>15th data and only keep one day (today)? So is it the scour script smarter
>than that, and will only start to delete files more than 24 hours old (so
>this won't work until I have new data beyond 18z today (2006021618)? Before
>I put this into a cron job, I guess I would like to know how it "thinks" of
>a "day".

The "ldmadmin scour" action will run the scour script conveniently for your
cron action. The scour script is based on the unix "find" command, where the
number of days is the "-mtime", eg time since last modified according to the 
system clock,
so "1" day means keep data up to 1 clock day old. You should start seeing
the data removed after the 18Z cycle yesterday is 1 day old. 

For the $GEMDATA/logs directory where the decoders are logging to, I
have an LDM crontab entry:
#
# rotate GEMPAK logs
0 17 * * * util/dcrotatelog.csh >/dev/null 2>&1

The dcrotatelog.csh script is can be copied to ~ldm/util from $NAWIPS/bin. The 
script
assumes that ~gempak/Gemenviron is symbolically linked to the current (eg 
~gempak/NAWIPS/Gemenviron)
Gemenviron file. It just runs the ldm "newlog" command (similar to your 
ldm-mcidas log rotation)
for each of the decoder log files found in $GEMDATA/logs.

Depending on your use of GEMPAK, your scour.conf entry could be as simple as 
scouring the
entire GEMPAK tree with a single number of days, or any number of separate lines
if you want more of some data, and less of others.

Steve Chiswell
Unidata User Support 

Ticket Details
===================
Ticket ID: GUX-304848
Department: Support GEMPAK
Priority: High
Status: Closed