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.
Hi Martha and Randy, Martha said: > I did what Tom suggested, edited the MCPATH in ~mcadde/.mcenv, but that > didn't fix the problem. My comments yesterday were about how to make your remote ADDE setup look more like the one I recommend for Unidata McIDAS. The current inquiry is tangentially, not directly, associated with that. > We are not storing the NEXRAD in the UNIDATA suggested hierarchy > (/data/ldm/nexrad...) but instead in /data/nexrad... I suspect that is > what is causing the problem. I thought that I edited all the CFG files > to reflect the different directory, but perhaps I missed some. A comment and a question: - the current Unidata procedure for NEXRAD Level III data serving uses the DIRFILE= approach, not the INFO=NNEXRAD.CFG approach. Both should work with no problems, but the INFO=NNEXRAD.CFG approach is not what is implemented in what 'mcxconfig' does. - you say you store your NEXRAD Level III files in /data/nexrad. What do the file names look like? (I do not use the SSEC approach for saving the NEXRAD Level III data, so I am not familiar with how the files are laid out on disk.) > What I edited, all in /home/mcidas/workdata, are NNEXRAD.CFG, > NEXRCOMP.CFG, and WNEXRAD.CFG setting up the DIRMASK to point to /data/nexrad. The template, ~mcidas/workdata/NNEXRAD.CFG (which is designed to be copied to a new file of a different name), has the following lines that are used: DIRMASK=/data/ldm/nport/nexrad/\ID/\TYPE FILEMASK=\TYPE_*.\ID IPMASK=* The DIRMASK portion is a regular type expression for the directory(ies) in which the files live; the FILEMASK portion is a regular type expression for the names of the files. This brings me back to the question above: - what do the file names look like for your NEXRAD Level III processing? > I would write to Tom telling him this, asking what we have missed. After your local copy of NNEXRAD.CFG is setup correctly (meaning that DIRMASK and FILEMASK match how your files are saved on disk), then you would setup ADDE serving of those data using: DSSERVE ADD RTNEXRAD/N0R INFO=NGCNEXR.CFG "comments etc. You may want to consider using the more standard DIRFILE approach as it is more in line with SSEC's approach (I developed the the INFO= before SSEC adopted my code for NEXRAD Level III serving). Please take a look at ~mcidas/data/LSSERVE.BAT to see what I am referring to for defining RTNEXRAD datasets. Randy said: > We just discovered that we are not able to see the NEXRAD data which is > coming in over noaaport. I believe with the SSEC mcidas-xcd the dataset > is called NEXRAD and the unidata is called RTNEXRAD. Yes, we use different group names for the ADDE datasets. This should not be any problem. > So when we now do a > dsinfo.k ALL RTNEXRAD we get all the datasets, although they have > different names then SSEC (e.g., N0R vs. BREF1). Correct again. I opted to name my dataset descriptors after the product names in NOAAPort. The BREF1, etc., names match those from the original WSI datafeed that Unidata universities used a number of years ago. > However, when we do an > imglist on RTNEXRAD/N0R ID=LWX it does not see the data that is clearly > there. This implies that the server mapping table entries for RTNEXRAD are not correctly setup for the way you are storing your files on disk. > Martha is researching this from home today, since it finally > snowed here, but I thought I would query you on this as well. I think that the solution will be simple. I will be better able to advise you after I know more about how your NEXRAD Level III files are saved to disk (i.e., directory structure and file naming). Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: STG-808468 Department: Support McIDAS Priority: Normal Status: Closed