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

Re: your mail



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

From address@hidden Wed May 30 15:37:24 2001
Received: from stratus.geol.iastate.edu (stratus.geol.iastate.edu 
[129.186.26.115])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id f4ULbNp16810
        for <address@hidden>; Wed, 30 May 2001 15:37:24 -0600 (MDT)
Organization: UCAR/Unidata
Keywords: 200105302137.f4ULbNp16810
Received: from synoptic.agron.iastate.edu (synoptic.agron.iastate.edu 
[129.186.20.16]) by stratus.geol.iastate.edu 
(980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id QAA11457 for 
<@stratus.geol.iastate.edu:address@hidden>; Wed, 30 May 2001 16:38:51 -0500 
(CDT)
Received: from localhost by synoptic.agron.iastate.edu via ESMTP 
(950413.SGI.8.6.12/930416.SGI)
        for <address@hidden> id QAA27738; Wed, 30 May 2001 16:37:22 -0500
Date: Wed, 30 May 2001 16:37:21 -0500
From: William Gallus <address@hidden>
X-Sender: address@hidden
To: Unidata Support <address@hidden>
Subject: Re: your mail
In-Reply-To: <address@hidden>
Message-ID: <address@hidden>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Steve,

The 3 files you mentioned (4 if I include master.nmap) are the ones I have
examined inside and out.  What I am finding is very baffling.  Everything
seems to match up exactly with the locations and filenames we give our
data.  But the programs are often failing.

All of our model data is in /data/gempak/hrs.  The AVN, ECMWF, and ETA
data is appearing fine in nmap (and I think in nmap2).  The MRF and RUC
data will NOT appear, even though the names shown for them in
datatype.tbl, yymmddhh_m.gem and yymmddhh_ruc.gem, are exactly what we
call them.  The fact that the Eta and ECWMF and AVN are working correctly
is what is peculiar.  In mod_res.tbl, I do have mrf1 and mrf2 showing up
for a lot of fields (and I've called both of these in datatype.tbl our
yymmddhh_m.gem runs).

I can't get any surface or upper air data to show up.  Our surface data is
in /data/gempak/surface/sao, and I've spelled that out in datatype.tbl in
METAR $GEMDATA/surface/sao YYMMDD_sao.gem, and for UAIR $GEMDATA/upperair
YYMMDD_upa.gem.  I also  changed master.nmap to say

/surface/sao METAR 60 0 0 YYMMDD_sao.gem
/upperair UAIR    180        0      0    YYMMDD_upa.gem

Yet, when I use nmap, and select OBS, it tells me "illegal data source,
check master.nmap"

I can get radar and satellite to work in nmap, but not in nmap2.  What is
even more bizarre is that our radar data has names like BREF1__010527_0110
and yet it is listed in datatype.tbl as *_YYYYMMDD_HHNN

When I first tried changing this to *_YYMMDD_HHNN (which seems to match
our data names), radar data would no longer work.

I am at a dead end.  Nothing seems to be following logic here.

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