[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010524: your mail

>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