19990828: Getting Updated Feeds to work (cont.)

>From: McIDAS <address@hidden>
>Organization: McIDAS proyect
>Keywords: 199908272226.QAA06927 ldm-mcidas XCD

Karli,

re: setting up XCD
>Actually I'm pretty sure that we had.  The one thing I didn't do was
>follow the steps to set up the GRID decoders, in the web instructions I
>beleive. Is this what I would need to do?

Setting up the GRID (GRIB) decoding will get you the GRID files from
the model output in the IDD.  This will not get you the NG and NF
products that were in the Unidata-Wisconsin datastream, however.  Those
products, while created from NGM and MRF initialization output fields
of model output that is in the IDD, are special in that the order of
the grids inside of the GRID file are preset.  The Unidata Fkey menu
system included in 7.50 relied on the ordering of the grids in these
GRID files to work.

In the McIDAS-X 7.60 release (announced on August 10), I included a
routine that can be used to create the NG and NF grids from the IDD
broadcast grids, thus allowing the Fkey menu to work.

>I know we have the disk
>space, so long as I set it up correctly. How do I make sure that those
>files are being scoured correctly?

Part of the installation process as presented in our McIDAS-X web pages
is the setting up of scrouing by cron-initiated execution of the mcscour.sh
Bourne shell script (this gets installed in the ~mcidas/workdata directory).
The idea is that one edits mcscour.sh and sets MCDATA, MCPATH, etc. to
match his/her McIDAS installation and then adds an entry in cron to run
mcscour.sh once-per-day.  mcscour.sh simply runs McIDAS scrouing routines
to delete MD, GRID, and TEXT data files that have been created by XCD.
One adjusts the scouring invocation lines (either doqtl.k or qrtmdg.k)
to set the number of days worth of these files to keep online at any
time.  Again, this is covered in the online McIDAS-X,-XCD web pages.

re: GOES-8 North American vs Mollweide images
>I'm sorry, that was a Mistake on my part, I meant the Mollweide
>Composite H2O dataset, but instead copied the wrong title. That is all.

No problem.  I just wanted to be sure that we were talking about the
same thing,

>DMAP AREA011
>AREA011                                                                       
>   
>PERM      SIZE LAST CHANGED FILENAME DIRECTORY 
>---- --------- ------------ -------- ---------
>0 bytes in 0 files

This shows one of two things:

o these images are not actually being decoded

  or

o you do not have a valid REDIRECTion to these files


>LA 110 119
>Done
>        
>DF 110 1
>DF: Specified image does not exist

These are telling us the same thing as the DMAP output.

>I'm pretty sure that we're receving the data, because it has always
>appeared up to date in the routing table. It must then be that they're
>not being properly decoded.  How can we check that then?

If they are showing up in the routing table, then the most likely thing
is that you do not have a valid REDIRECTion to the ouput data files.
Check your REDIRECTions:

REDIRECT LIST

and see if there is anything that _should_ match AREA011.  If there isn't,
or if it is pointing to the wrong directory, then you need to change it.
If you do, please send me the output from the following:

ROUTE LIST
REDIRECT LIST

>The IR
>Composite also calls a MOLL.BAT in the post process, but it only creates
>a composite IR/Topo image, (can it be modified easily for H2O?)

The problem with attempting to composite the Water Vapor with the topography
is that the water vapor images data  values basically occupy each display
space point.  You can play with this, however, by looking at the source
code for NORTMAPR (nortmapr.pgm) and adding support for composite H2O
images.  If I get a chance, I will play with this to see what might come
out.

>I'm sorry, the section which I'd skipped under the XCD Instructions were
>the section on decoding GRIB messages and not GRID messages as I'd
>previously stated. 

No problem.  Even though you just got up 7.50, you may want to consider
upgrading your installation to 7.60.  The only consolation I can give
for this new bit of work is that it is easiest to upgrade while the
installation/configuration steps are fresh in mind.  The other thing about
7.60 is that I do not plan on supplanting it with a new version (i.e.
7.70) until next summer.  I will, however, be updating 7.60 with "addenda"
as new code becomes available or bugfixes are developed for existing
problems.

Tom Yoksas