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

[no subject]



Bill,

The pattern/actions I provide, as well as the default datatype.tbl settings
use the YYYY naming conventions. The tables that you need to look at for NMAP2
are:

$NAWIPS/Gemenviron
        Ensure you have the correct paths defined for:
                RAD, SAT, GEMDATA, MODEL, HDS

$GEMTBL/config/datatype.tbl
        Using the variable locations defined in Gemenviron, and file name 
templates,
        The defaults I provide match the pqact.conf pattern/actions I provide
        in the GEMPAK web pages.

$GEMTBL/nmap/mod_res.tbl
        The lists for models such as MRF determine what possible products
        are available when youclick on "grid".


Since you can't see MRF, determine what model group you expect this as, eg
in the mod_res file, there are the possible types: mrf1, mrf2, mrfx. 
Depending on what you want to call your mrfx files, you might have to define
in datatype.tbl:
MRFX   $MODEL    YYYYMMDDHH_mrf.gem   CAT_GRD  SCAT_FCT   -1     -1     -1

If you don't get any times for METAR/UAIR, the defaults assume:
METAR files for today would be in $GEMDATA/surface/20010530_sao.gem
UAIR files for todat would be in $GEMDATA/upperair/20010530_upa.gem

Check your GEMDATA environmental variable in Gemenviron to see that it is set
correctly.

Some general upgrade suggestions from the installation documentation I provided:
1) create a new "clean" directory for a new installation. I know this assumes
that you can afford 300MB or so, but it would prevent clobbering old 
distributions
when you upgrade, and you can use the old modifications for reminders.

2) If you can do #1, at least back up the current tree before upgrading.

3) Do periodic system backups of your critical software. This will come in 
handly
if you have hard disk crashes or worse...hackers.

4) When you modify a file, create a copy. For example, when you modify
datatype.tbl, you might copy the last "working" configuration to 
datatype.iastate.
Then, if you make modes that don't work, you can revert. Or, if you unpack
a tarfile over top of datatype.tbl., you will still have your local file.

Steve Chiswell
Unidata User Support


>From: address@hidden (William Gallus)
>Organization: UCAR/Unidata
>Keywords: 200105251954.f4PJsep02776

>Hello,
>
>Our computer person Geff went ahead to make the change that you
>suggested would allow profiler data to work within Garp with newer gempak, but
>  he
>did so by installing the binary with patch, and not just compiling
>the patch alone.  Therefore, we've lost all of our "tweaked" versions
>of files that had allowed garp and nmap, nmap2 to work on our machines,
>and there is no back up of any nmap, nmap2 files.
>
>After fits of anger, I've been able to get garp to work again, and
>I see the patch has worked.  That is it for our good news, though.
>
>I need to know what all files could be playing a role in the following
>nmap/nmap2 problems.  I have changed our $GEMTBL/config/datatype.tbl
>and our $GEMTBL/nmap/mod_res.tbl and master.nmap files to match what
>I "think" are our data locations and naming conventions.  Despite 
>these files looking correct to me, I am getting the following problems:
>
>when I select radar data in nmap, it doesn't allow me to do anything but
>"close" (not accept).  The radar data worked fine in nmap y'day.
>
>when I select OBS in nmap, it claims "Illegal data source,
>check master.nmap".  In nmap2, I don't get any times showing up
>after selecting METAR, or UAIR, or even SAT (which is one of
>the few things working fine on nmap)
>
>Most bizarrely, it is seeing the Eta and AVN and ECMWF data in both
>nmap and nmap2, but not our MRF or RUC data.  I know RUC won't work
>in nmap because of the large number of files, but it now isn't working
>in nmap2 either, and the MRF files are very small, and worked fine
>yesterday.  And as I said, the names look correct in datatype.tbl and
>mod_res.tbl.
>
>I appreciate any help you can give me.  It is so frustrating that
>every time we upgrade, we end up taking 1000 steps backward.  That
>is one reason I am very reluctant to ever upgrade anything we have
>already working!
>
>
>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                      *
>**********************************************
>