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

20001230: McIDAS FRNTDISP probs



>From: address@hidden
>Organization: SMSU
>Keywords: 200012301857.eBUIvlo29945 McIDAS-X 7.7x FRNTDISP

Bill,

>I have installed v7.7.  It runs.

This is a less than auspicious beginning to an email :-(

>I have 2 problems with FRNTDISP...for which I have been using FRONT til now.

OK.

>1. Is just a whine, or maybe related to 2.  FRNTDISP returns a code 2 upon not
>finding data, which blows BATCH files (if we didn't use CONTINUE=YES), if run
>interactively it produces ugly yellow text in the text window.  Whine.

Actually, all McIDAS routines are being/have been modified to return
error codes when they don't successfully run to completion.  This is
useful in McIDAS BATCH (IF NOT ERRORCODE) and MCBASI (STATUS) and Unix
shell scripts since the error condition can be trapped and used in
logic flow control.  The downside is that old scripts have to be
retrofitted to take advantage of this.

>2. Is a real problem.  ASUS1 files get put in /var/data/surface/front.  A
>REDIRECTion in mcidas allowed FRONT to find them there.  FRONTDISP can't
>find them...

FRNTDISP doesn't use the ASUS1/FSUS2 files at all.  Instead it does an
ADDE transaction to a RTWXTEXT dataset which must be setup to extract
the information from the daily textual spool file.

>they're there, but FRNTDISP says front not available for    15   (or
>whatever time...and they do exist)

This tells me that the ADDE server that is being asked for the data doesn't
have it for some reason.

>I've read the discussion of GROUPS for FRNTDISP, looked around a little bit,
>but can find no definition of fronts for the ADDE data sets.  What did I miss?

The setup for getting fronts from ADDE relies on the following two lines
being in the file WXCORE.PRD on the ADDE server:

FRONT_ANAL                WMO=ASUS1 WSTN=KWBC
FRONT_FCST                WMO=FSUS2 WSTN=KWBC

Check your ~mcidas/data/WXCORE.PRD file to make sure that these two lines
are there.  If they are not, then we have to figure out why they are not.

SMSU IDD ingest problems:

I had been meaning to touch base with you about your data ingest problems,
but this past week was entirely too hectic to get anything not remotely
related to the introductions of NEXRAD NIDS products into the NOAAPORT
stream done.

If you are still having IDD problems, and if your use of data is mainly
for creating displays for web pages, and you basically use just McIDAS,
then you might be better off going out to an ADDE server that is maintained
remotely for your data access.  There is such a machine that is now
open for use: adde.ucar.edu (I havn't had time to announce it yet, but
I will soon).

On adde.ucar.edu, you will find all of the datasets that are created by
McIDAS-XCD and more.  In addition, the amount of data that we maintain
on this machine is _much_ more than a typical Unidata McIDAS site maintains
locally (e.g., 9 days of MD data; 9 days of GRID data, 7 days of RTIMAGE
data, 15 days of RTGINI data (GINI is the imagery in NOAAPORT, etc.).
When the NOAAPORT single station radar data starts flowing on Monday,
all of it will be accessible by ADDE as well (this will take some
education about access, and will need installation of an addendum that
I will be putting together on Tuesday).

So, if you need to try something else for data access (i.e., you just
can not get data via the IDD for whatever reason), and are willing to
ADDEize your product generation scripts, then you should give ADDE
access to adde.ucar.edu a whirl.

We will be making more ADDE servers operational across the country
in the coming weeks/months/etc. so that not too many sites start hitting
the same server for their data.

If you want to give adde.ucar.edu a try, do the following:

DATALOC ADD INFO ADDE.UCAR.EDU
DSINFO T INFO
READ INFO/RTSERVER
READ INFO/RTSERVER DEV=T RTSERVER.BAT
BATCH RTSERVER.BAT
DSINFO I RTGINI
IMGDISP RTGINI/GE1KVIS STA=KSTL EU=IMAGE REFRESH='EG;MAP H'
IMGDISP RTGINI/GE1KVIS STA=KSTL MAG=-2 EU=IMAGE REFRESH='EG;MAP H'

(Of course, display of the 1 km VIS images is best done during the day :-)

If you decide to not use this setup, you will need to change
your DATALOCations back to they way you had them before running the
RTSERVER.BAT file that is created in a READ step above.

Give the above a shot and let me know what you think.  If you need any
ideas in converting existing McIDAS scripts to using ADDE routines,
please let me know.

Have a great New Year!

Tom