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

20010531: your mail

Bill,

Thanks for the update.

The satellite and radar file naming may be more particular about the 4 digit
YYYY naming. Have you tried creating a directory of 4 digit year names
and see if NMAP2 works with that?  I have the ldm pattern/actions for filing
the NEXRAD and WSI feedtype data with YYYY naming if you need that-
I realize that this may effect your other scripts that use the data.

I'm in the middle of folding in the 5.6D changes from NCEP regarding NMAP2-
I see they have reworked that entire section of code. 

Steve Chiswell
Unidata User Support



>From: William Gallus <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200105311743.f4VHhWp15591

>Hello,
>
>I just wanted to let you know we figured out the bizarre problems we were
>having -- we didn't realize that the column positioning of the parameters
>in datatype.tbl was so important.   Once we made sure columns were the
>correct width, the problems were solved, for the most part.  The only
>remaining problem is that nmap2 still refuses to access our radar data,
>but nmap has no problem with it.  This is a problem I had originally
>mentioned to you back on Tuesday, prior to our loss of customized files.
>You suggested a change similar to what you had done in nmap2 to allow more
>model files than in nmap.  To do this change, we need to grab the code and
>compile ourselves -- we have just been using binaries so far.  We may try
>that; otherwise we will probably rely on nmap more than on nmap2.
>
>Thanks for all of your help this week.
>
>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 Wed, 30 May 2001, Unidata Support wrote:
>
>> 
>> 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 NMA
> P2
>> 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 templ
> ates,
>>      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 se
> t
>> correctly.
>> 
>> Some general upgrade suggestions from the installation documentation I provi
> ded:
>> 1) create a new "clean" directory for a new installation. I know this assume
> s
>> that you can afford 300MB or so, but it would prevent clobbering old distrib
> utions
>> 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 h
> andly
>> 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.ia
> state.
>> 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                      *
>> >**********************************************
>> >
>> 
>> ****************************************************************************
>> 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/     
>> ****************************************************************************
>> 
>