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: William Gallus <address@hidden> >Organization: UCAR/Unidata >Keywords: 200105241923.f4OJNpp24321 >Thank you for your help. With regard to the RUC issue, I believe you are >correct that we have too many files, since we do receive the data hourly, >and have an on-line archive back 7 days. Is there any easy way for us to >avoid the problem happening with nmap, other than to limit our on-line >archive? Bill, You can increase the array sizes of 2 variable in nmap the way I have increased them in nmap2: $NAWIPS/nprogs/nmap/source/nmap_dslw.c gdclst[4096] --> gdclst[12000] tmptim[100] --> tmptim[1000] I primarily use nmap2, because it provides much more flexibility with the number of data sets that can be displayed, as well as multiple looping frames etc. > >I have another question which might be related. In nmap, our radar data >shows up fine. However, in nmap2, after one selects the radar product >(such as DMX, BREF1), nothing shows up in the time section. It appears as >though it isn't seeing any data. However, after I gave up, and decided to >plot a model plot, it seemed to overlay the model data on a static radar >image that had a badly messed up color enhancement. I was wondering if >nmap2 might have a problem with too many radar images being available, >while nmap doesn't seem to have this problem? You can try creating a directory that has fewer products in it and see if that fixes the problem. If so, then it would be an array size problem. I generally keep about 60 products in a directory and don't have problems with that size in nmap2. How may products are you talking about? > >Bill > > >********************************************** >* Bill Gallus * >* Associate Prof. of Meteorology * >* Dept. of Geological and Atmospheric Sci. * >* 3025 Agronomy Hall * >* Iowa State University * >* Ames, IA 50011 * >* (phone) 515-294-2270 * >* (fax) 515-294-2619 * >********************************************** > >On Thu, 24 May 2001, Unidata Support wrote: > >> >From: address@hidden (William Gallus) >> >Organization: UCAR/Unidata >> >Keywords: 200105241438.f4OEchp14879 >> >> >Hello, >> > >> >After spending a week at SPC where they used NMAP heavily (and NMAP2), >> >I'd like to switch all of our computers over to the newer gempak >> >versions that allow nmap. We've already upgraded gempak on some linux >> >boxes, but there is one annoying problem we can't solve. >> > >> >If I use sncross or sncross2 to plot profiler data on a machine that >> >has the newer gempak, it works fine. However, when I use garp there >> >to view profiler data, >> >I get a core dump after selecting an individual profiler site. All >> >the other features on our garp seem to work fine -- the exception is >> >the profiler data option. It appears as though it tries to use >> >sncross, yet it does a core dump. On our machines with older gempak versio > ns, >> >there is no problem with this option or any in garp. Our Garp_defaults >> >file seems to match what worked on the older machine. Any ideas of what >> >might be wrong? >> >> There was a change in the GEMPAK 5.6 gemlib calls which affected the number >> of parameters that are passed to several routines. I posted source patches >> for Garp in GEMPAK 5.6.a that fixed 2 bugs, one in plotting profiler >> data, the other in plotting radar rings. These routines are in: >> ~gbuddy/nawips-5.6/patches/garp >> >> I also repacked the source distribution tar file and reposted the GEMPAK 5.6 > .a >> binary files on January 29th for sites who were using the solaris, X86, or L > inux >> releases. All these changes are in the current 5.6.c.1 release which also >> includes many additional features and bug fixes for NMAP/2. >> >> >> >> > >> > >> >I also have a few questions regarding nmap. First, if we only are getting >> >a subset of all the models that show up as options within nmap, and I >> >only want the ones we receive to show up in the clickable menu, is there >> >a file I can edit to get this to happen within nmap or nmap2, or do I >> >simply have to delete from $GEMTBL/config/datatype.tbl the models we >> >aren't receiving? >> >> The list of models which appear in the GRID selection are those in >> $GEMTBL/nmap/mod_res.tbl. For example, if you don't want "nww3" to appear >> in the grid selection, then remove it from all model lists in the file. >> >> >> >> > >> >Next, we do receive the 212 grid via CONDUIT. I tried changing our >> >entry in $GEMTBL/config/datatype.tbl to match what we call that data, >> >YYMMDDHH_eta_grid212.gem, and found that the name is so long that >> >the last character bumps into the next column of information (CAT_GRD). >> >Although I made this change, the ETA212 option in nmap or nmap2 still >> >shows no valid times - which implies to me our naming convention might >> >be too long. Is that a possibility? >> >> The table is white space delimited, so make sure you have a space between >> the template and the category. The template can be 25 characters. >> The template you show above is 24 characters which should be OK, unless you >> start using YYYY instead of YY. >> >> >> >> > >> >Finally, although our datatype.tbl option appears correct for the RUC >> >model, within seconds of selecting it from the clickable menu within >> >nmap, there is a core dump and nmap vanishes. Yet, RUC does work as >> >an option within nmap2. What is the likely reason for a core dump >> >within nmap but no problem in nmap2? >> >> Its possible that the total number of times or files exceeds the array >> size in NMAP. I boosted the array sizes in NMAP2. If you have hourly >> RUC files for several days, you are much more likely to hit an >> array size with that model- as compared with any other 2x or 4x per day mode > l. >> >> >> > >> >Thanks, >> > >> >Bill >> >********************************************** >> >* Bill Gallus * >> >* Associate Prof. of Meteorology * >> >* Dept. of Geological and Atmospheric Sci. * >> >* 3025 Agronomy Hall * >> >* Iowa State University * >> >* Ames, IA 50011 * >> >* (phone) 515-294-2270 * >> >* (fax) 515-294-2619 * >> >********************************************** >> > >> >> >> Steve Chiswell >> Unidata User Support >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8644 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://www.unidata.ucar.edu/ >> **************************************************************************** >> > Steve Chiswell Unidata User Support