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.
>From: "Happel, Shelly" <address@hidden> >Organization: USF >Keywords: 200306121710.h5CHA3Ld017681 McIDAS NLDNDISP web pages Hi Shelly, >Thanks again! I made the change to the script and ran it again. From what I >can see the log file says dsserve.k done. That's the only line it added. OK, I am convinced that the problem is caused by the lack of definition of RTPTSRC dataset elements. The DATALOC command says that all RTPTSRC data will be accessed as LOCAL-DATA: dataloc.k* ADDE_ROUTE_RTPTSRC LOCAL-DATA but there is no definition in place _for the routines being run_ by the web server. Yesterday afternoon I tried to plot a variety of RTPTSRC data using metlab.cas.usf.edu as the ADDE server, and they all failed. I have to think that this is a result of your blocking displays that are not in your local domain, which is OK. I was a little suprised, however, that the user 'mcidas' running on metlab.cas.usf.edu can not go through the remote ADDE interface that _is_ setup on metlab. I found this out by logging onto metlab and becoming 'mcidas' and then: cd workdata dataloc.k ADD RTPTSRC metlab.cas.usf.edu ptlist.k RTPTSRC/LIGHTNING -- this hung -- I change the pointing back to LOCAL-DATA: dataloc.k ADD RTPTSRC LOCAL-DATA and then attacked the problem in the web server context. I did this by creating a RESOLV.SRV file in the /usr/local/apps/php-apache/htdocs/sridhara/mcidas/data directory. RESOLV.SRV is the file that contains the definitions for datasets (mapping from dataset group/descriptor (e.g., RTPTSRC/LIGHTNING) to the files that compose the dataset (MDXX0071 - MDXX0080 in the case of RTPTSRC/LIGHTNING). Since all of the needed definitions were already included in the version of RESOLV.SRV that had been created in the McIDAS account (~mcidas/workdata/RESOLV.SRV), I simply copied that file to the directory above. I saw that the 'mcidas' version of RESOLV.SRV had some extra dataset definitions in it, so I deleted these in the copy. I think that now that the web driven routines will have a dataset definition file accessible, the NLDN plotting should work. Please try this out as soon as you can and let me know the results. If it does work, please remember to remove the logging additions that you made to the gen_mcidas* script(s). >I know there are some issues with our data feed... Huh? I just took a look at the latency plots for the various feeds you are getting with the LDM, and don't see any problems with metlab receiving data. I did notice that the pointing for various datasets in the 'mcidas' account (defined in ~mcidas/data/ADDESITE.TXT) has McIDAS routines going out to remote servers for datasets that should be available locally (e.g, RTIMAGES, RTWXTEXT): ADDE_ROUTE_RTIMAGES=PAPAGAYO.UNL.EDU ADDE_ROUTE_RTWXTEXT=ATM.GEO.NSF.GOV or could be available locally if LDM were setup to request the data (e.g., NEXRCOMP, RTNEXRAD): ADDE_ROUTE_NEXRCOMP=PAPAGAYO.UNL.EDU ADDE_ROUTE_RTNEXRAD=ATM.GEO.NSF.GOV but I do not notice any data reception problems. >Arlene tried to use it last >night in the student lab and had some problems. What exactly? >Sigh..... She's talking >about sending me back to you folks in Oct/Nov for training and I think I'll >be able to get a lot more out of it this time since I've had more experience >with LINUX and with the data sets. Well, traveling to Boulder should not be considered a hardship :-) >Attached is the latest log file. I hope we can figure this out - I really >really appreciate your help. I think that my creation of a RESOLV.SRV file in the first MCPATH directory defined in the gen_mcidas* scripts should solve your NLDN display problem. You will have to try the plots and let me know if things are working. Tom