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

20020924: data scouring at STC (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20020924: data scouring at STC (cont.)
  • Date: Tue, 24 Sep 2002 14:36:48 -0600
>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200209232129.g8NLTo103996 McIDAS-X mcscour

Hi alan,

>Glad to see you are still in such fine form regarding the problems
>of us basic operators.
>
>Regarding our set up,  we access the data files stored on our ingestor
>(waldo) which runs the ldm and mcidas decoders.  Right now it serves 7 other
>terminals.  I also plan to begin upgrading to MCIDAS 2002 on these 7 machines.
>At present, we run ver. 7.705

I thought that you were running an old version of McIDAS.  There has been
some worthwhile improvements in McIDAS since 7.705, so upgrading would
be a "good thing".

>MCIDAS is the only package running now, so perhaps your advice about saving 
>additional AREA files should be tailored to that case.  

OK.

>Sometime this year, we will also start running GEMPAK, and once that happens, 
>I will ask again since the method of saving is apparently different.

Actually, we could get waldo setup to store the imagery in a directory
hierarchy that GEMPAK (GARP and NMAP2) can use.  McIDAS ADDE doesn't care
about the difference as it can support both.

What I propose doing is the following:

1) review exactly how your other machines running McIDAS access data
   from waldo (you may understand this, but I don't).  What I mean
   is are the other machines all using ADDE to access the data on
   waldo, or are they using NFS mounts off of waldo?

2) changing the way imagery is stored on waldo to a way that GEMPAK
   can use

3) adjusting the ADDE serving of the imagery stored on waldo in the
   new way so that you will save more of the products you want.

All of this shouldn't take that much time, but there are a number of
little things that can cause some snags.

I guess another question that I should ask is if you use the composite
imagery that can be created by the Unidata-Wisconsin images?  The
composites are the East-West composites of VIS, IR, and H2O, and the
various composites of these images with topography images.  The reason
I ask is that the setup to create these composites on the local machine
use the McIDAS routing table (ROUTE.SYS).  If the storage of the images
is changed to the method that files them into a directory hierarchy and
naming convention used by GEMPAK, the use of the routing table goes
away (unless you run both in parallel) and with it, the composites.

If you are game, I could jump onto waldo and setup the parallel filing
and change the ADDE serving of data to use of the new image stores.
The harder part is keeping the compositing alive when switching over
to the alternate filing method.  Please let me know what you would 
prefer.

>Meanwhile, I will go ahead and change the MD and GRID scouring.

OK, good.

>Thanks Tom    

No worries.

Tom