>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
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.