>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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.