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

[no subject]

>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 versions,
>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 
Linux 
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 model.


>
>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