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

Re: 20000727: Display of CIMSS sounder products in GEMPAK

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20000727: Display of CIMSS sounder products in GEMPAK
  • Date: Wed, 2 Aug 2000 10:21:12 -0600
Robert,

Guess I should ask if this is X86 or linux.

This sounds like the imrtbl.f routine hasn't been updated to read the new
entrieds in $GEMTBL/sat/imgtyp.tbl.

First, verify that the imgtyp.tbl tables does have the lines:
! CIMMS products from Unidata/Wisconsin data stream
SOUNDER              CTP           0    255     75  2**26      1 ctp_upc.tbl
SOUNDER              PW            0    255     75  2**27      1 pw_upc.tbl
SOUNDER              LI            0    255     75  2**28      1 li_upc.tbl
SOUNDER              CAPE          0    255     75  2**29      1 cape_upc.tbl
SOUNDER              OZONE         0    255     75  2**30      1 ozone_upc.tbl
SOUNDER              SST           0    255     70  2**30      1 sst_upc.tbl


Then, verify that the $GEMPAKHOME/source/gemlib/im routienes got updated
(Linux gmake may be problematic about this):

Lets clear those routines outt of gemlib.a and then run make to
ensure that you have the latest versions:

cd $GEMPAKHOME/source/gemlib/im
ar dv $GEMLIB/gemlib.a imar2gm.o imcalib.o imdrop.o imrtbl.o
make all
make clean

Then rebuild garp and the programs:

cd $GEMPAKHOME/source/programs
make clean
make all
make install
make clean

cd $NAWIPS/nprogs/nsat
make clean
make all
make install
make clean

cd $GARPHOME
make clean
make all
make install
make clean


The new entries in the imgtyp.tbl table are of the form 2**x, and the
imrtbl.f routine must be updated to read those numbers. X86 should
update those library routines with no trouble, but gmake for Linux (and
X86 if you aren't using /usr/ccs/bin/make) for some reason fails to add
the new .o files to the library. I've rewritten the makefiles for
the next release for just that problem (a lot of makefiles).

Steve Chiswell
Unidata User Support




You should have the lines:

On Wed, 2 Aug 2000, weather wrote:

> Steve,
> 
> I had a quick minute to run gpmap and still no image..this time
> I just had a map of the US..the area I selected.
> 
>