20021021: data ingestion/decoding/filing/scouring at STC (cont.)

>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200209232129.g8NLTo103996 McIDAS-X mcscour

Hi Alan,

>I think I sent the message just below  around  1  Oct, but it must have 
>gotten lost.   It includes additional information & questions regarding
>data scouring on our site. 

I must apologize for not jumping on this one.  I will work on this today.

>Regarding the above issue,  I have changed the scouring for MD and GRID files
>as you described above.   In the meantime, I cleaned up the disk so we are 
>stil running at about 50% disk usage.
>
>Regarding our setup,  our laboratory terminals  access the data on our 
>ingest machine, waldo, which runs the ldm and mcidas decoders.  Since we 
>are still running on MCIDAS 7.705,  we need an NFS mount to waldo for each
>or our terminals,  and waldo is also listed as the ADDE site for all the 
>dataset types.  My understanding is that while much of the data is accessed
>through the ADDE listing,  some MCIDAS commands in this version (7.705) still
>need the NFS mount.  I don't know whether the AREA files are accessed by 
>ADDE or through  NFS,  but you do.

Would it be possible to get the login information for a non-'mcidas'
user on a machine other than waldo?  This way, I could refresh my
memory as to what was not there in v7.705.  (After all, 7.705 _is_
three revisions ago, and I am getting old :-)

>If I read your release message correct, installing ver 2002
>will mean that the NFS mount is no longer necessary.

I can only say this with assurity after I see and understand the setup
on a machine that is currently accessing data on waldo through NFS.

>Regarding composites,  we do use these, and I don't think we would like to
>give them up.  I guess this means we are interested in a parallel setup. 
>Does this mean we keep two copies of the file ?

Yes, but this is not as bad as it seems.  The process for creating the
composites relies on the McIDAS routing table, ROUTE.SYS.  The routing
table uses pre-ADDE concepts for access of data files (by file number,
not by ADDE dataset group/descriptor).  So, in order to keep compositing
the GOES-East and GOES-West images (and topography), waldo will need
to keep ingesting the GOES-East and GOES-West VIS, IR, and WV images
using routing table concepts.  Now, it only has to keep one of each,
so the disk usage is not nearly as bad as it sounds.

>That may not be a problem
>as we have disk space, especially if it can be on another machine.  

I don't think that disk space will be a problem.

>Also,  as I noted earlier, we will want to run GEMPAK fairly soon,  a little 
>later this year, so we would like to plan for that.

Got it.  My intention is to setup image ingestion/decoding/filing in
a manner that will be immediately useful for GEMPAK.  Setting up other
decoding for GEMPAK (point data and grids, for instance) is something
that has to be done by the person that installs GEMPAK.

>Given the above,  you are welcome to look and or change things on waldo;
>Let me know if you need the pw,  perhaps you still have it.

I have the login to waldo.  I really do want a login to a user account
on a machine other than waldo so I can really see how McIDAS is being
used now.  For instance, are you still using the Fkey menu?

>If this adjustment would all be much simpler after we have upgraded to 
>ver 2002,  then let me know.  We can try and speed that up.

It would be easier to work with IF folks are using the MCGUI.  If the
Fkey menu is still being used actively, I am not sure what the outcome
of upgrading would be (it shouldn't be much of anything, but I don't
want to state that categorically without getting a better idea of how
users are working).

>I would like to know the details of what needs to  change;  perhaps there
>is a section in the ldm and/or MCIDAS docs you can point me to

Changing how the images are ingested/decoded/filed is not a separate
section of the McIDAS documentation mainly because I have not developed
a truely clean way of creating the composites without the routing table
concepts.  The pqact.conf actions for decoding and filing the images
in a manner to be used by GEMPAK are provided with the current ldm-mcidas
distribution (v7.8.0) in the ldm-mcidas-pqact.conf file.  These actions
take advantage of the flexibility of the ldm-mcidas PNG compressed
AREA decoder, pnga2area.

>Thanks Tom

As soon as I get the separate "student" login, I will examine the best
way to upgrade your image decoding.

Tom