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

20030317: scouring *.XCD at stc (cont.)

>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200303111741.h2BHfFB2012143 McIDAS-X v2002 setup

Hi Alan,

>I came in and checked waldo again on  16 Mar. and again found
>3 days worth of the  D*.XCD files.

This is not good.  It implies that the scouring is not working as it
should.

>Not sure if this would 
>continue beyond 3 days, but it looks like the scour process 
>is not working right for these files.

I agree.

>I think your earlier 
>message noted we should only be seeing  1 day's data in this file.

That is correct.  The entry for scouring .IDX and .XCD files in mcscour.sh
says to keep 1 day online.

>Is the no. of  D*.XCD  files that are saved adjustable ?

Yes, but it is already set to be 1 day.

>I assume 
>that if we want to save 2 or 3 days of surface data, that this is 
>the group of files (along with *.IDX ?) that needs to be saved.  

There are two things here: the decoded surface, etc. data and the
undecoded data.  The first set of data is stored in MDXX files.
The second set is stored in .IDX and .XCD files.

>I believe we had earlier decided we wanted 3 days of sfc data, but 
>I do not remember editing the mcscour.sh file.

When I was on waldo, I saw that the copy of mcscour.sh that was to
be run from cron was setup to keep 3 days of surface, etc data
which will be found in your MXX files.

>Can you point me to how I would change the no. of days that would 
>be saved for this file type ?

Login as 'ldm' and verify that there is a crontab entry setup to run
mcscour.sh.  Find out where the copy of mcscour.sh is to be located
and do the following:

o cd to that directory
o verify that the script is executable by the user running the cron
  entry
o edit the script and look for the settings at the bottom of the file.
  They will look something like:

MCPATH=$MCPATH PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH mcenv << EOF

qrtmdg.k GRID 5001 6400 1
doqtl.k  1  70 3
doqtl.k 71  80 3
doqtl.k 81  90 3
doqtl.k 91 100 3
delwxt.k 1 10
igu.k DEL 132
lwu.k DEL VIRT9001
lwu.k DEL VIRT9002
lwu.k DEL ROUTEPP.LOG
exit

EOF


The doqtl.k entries scour MDXX files.  The syntax is:

doqtl.k bcyl ecyl ndays
         |    |     |____ number of days of MDXX data in files 'bcyl' to 'ecyl'
         |    |           to keep online
         |    |__________ ending cylinder number for range of MDXX files
         |_______________ beginning cylinder number for range of MDXX files

The listing above is exactly equivalent to:

qrtmdg.k GRID 5001 6400 1
doqtl.k  1 100 3
delwxt.k 1 10
igu.k DEL 132
lwu.k DEL VIRT9001
lwu.k DEL VIRT9002
lwu.k DEL ROUTEPP.LOG

The qrtmdg.k entry is used to scour GRID files.  Since you are not using
XCD to decode GRIB messages (model output) into GRID files, this entry
will do nothing.

>Edit the line in mcscour.sh  that
>reads  delwxt.k  1  10  ?   Does the '1' in my present line indicate 
>that only 1 day should be saved ?

The delwxt.k entry is used to scour .IDX and .XCD files.  The syntax is:

delwxt.k nday  nprevday
          |       |_____ number of days before today to include in range of
          |              files to check for scouring
          |_____________ number of days of data to keep online


This entry entries _should_ leave you with only one day of .IDX and
.XCD files online.  Since it is not, we need to figure why.

>Let me know what you think I could try.   I will turn telnet back on
>for you if you need it.

The fact that the MDXX files are being scoured and the .IDX and .XCD
are not is a mystery to me, so I have no ready answers.  I will need
to poke around to figure out what is going on.  The first thing I would
try, however, is to:

<login as 'mcidas'>
cd workdata
delwxt.k 1 10

and look for any weird output from delwxt.k.

Tom