[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010524: your mail
- Subject: 20010524: your mail
- Date: Fri, 25 May 2001 10:31:10 -0600
>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