20051206: MCIDAS--more data problems

>From: "Corcoran, William T" <address@hidden>
>Organization: Missouri State
>Keywords: 200512062234.jB6MY97s009689 McIDAS-XCD ADDE

Hi Bill,

>I've built the latest MCIDAS on our "new" machine...somebody's cast off
>computer (only 384 M RAM) with a new disk.  Fedora Core 4 downloaded and
>installed.  That was fun.  I think it took about an hour to do the
>system,  and about 5 minutes to build Mcidas.  On the AIX machine the
>system was a 2 day operation and Mcidas was on the order of 12 hours.
>Man, I love technology.  We may bring the men's room in from the pasture
>next.

Sounds good so far...

> It took me a few days to get the network and HTTPD (apache) working
>(selinux was apparently a problem),

It is also a problem (challange) for the LDM logging as well.

>so now I'm at the point of trying to
>move things from cumulus, our old AIX box to the new machine (creatively
>named stratus.missouristate.edu).

OK.

>Since Nov 30, both machines have had trouble accessing ADDE data from
>all the different servers.  In particular, we use RTIMAGES/MDRTOPO, and
>these don't seem to be created anymore (servers all report 10 images,
>none current).  It doesn't seem to matter whether I hit up UCAR,
>PAPAGAYO, NOAA, NSF, NIU, etc.  For a week or so after Unidata made the
>server switch for ADDE, we couldn't get them there, so I had
>"discovered" NIU3 in our email exchanges.  It "worked" for a week or
>so....now even that one doesn't seem to want to serve cumulus MDRTOPO.

This must be a problem on the data injection side.  I will need to
take a look.  Since you have upgraded McIDAS, I would suggest that
you investigate switching to use of NEXRCOMP composite radar
images (national composites created from individual NEXRAD displays).
This radar imagery is _much_ better than the MDR stuff.  To
access the NEXRCOMP imagery, do the following:

dataloc.k ADD NEXRCOMP adde.ucar.edu

>Today (Dec. 6) we seem to have trouble getting RTPTSRC surface data.  We
>had stuff up to 12 Z, but since then SFCCON reports no data fitting the
>request, and this is with a straight vanilla request:
>
>e.g., from cumulus
>
>SFCCON PMSL     GRA=3D1 IMA=3D1  NAV=3DC
>Accessing Dataset Name =3D RTPTSRC/SFCHOURLY.ALL
>PTCON: No data found matching search conditions
>PTCON:  Done
>SFCCON: PTCON command failed
>
>Dataloc.k yields (edited)
>RTPTSRC                      ADDE.UCAR.EDU
>
>This of course is all in a script that has worked fine for years (I hate
>saying that).  Results on stratus.missouristate.edu are identical.

Thanks for reporting this.  For some reason, the McIDAS surface decoder
starting failing with a segmentation violation at around 12Z today.
Since I have not been looking at the weather today (even though it is
snowing in Boulder), I didn't notice the failure.  Ouch, the decoder
started failing with segmentation violations on all machines running
it at the same time!?

>What this is doing is playing a merry tune on my brain as I try to make
>stratus.missouristate.edu a working machine.  I'm unsure whether or not
>the problems are mine or someone else's.

The problems are apparently mine.

>Some data sets are working...the RAOB's for instance do just
>fine...hmmm, anything happen at 12Z today?
>
>Anyway, your comments are appreciated on why we can't access data.

I don't know why the surface decoder is failing.  Find out will
take some time.

>Right now the dataloc is scattered around the country.  The installation
>is real rough, the result of just running the basic Unidata scripts for
>data sets and locations...nothing's been cleaned up.

OK.

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.