[GEMPAK #GUX-304848]: GEMPAK and GARP

Jennie,

> I guess I hadn't run make install in the right directory 

In general, the entire gempak package can be built from $NAWIPS with:

make everything

which is a shortcut to running the commands:

make clean
make all
make install
make programs_nc
make programs_gf

(http://www.unidata.ucar.edu/software/gempak/GEMPAK/Install_GEMPAK.html)
Of course, if the downloaded binary distribution could be installed, then
you wouldn't have to do that step!

>ldm@eurus gfs]$ pwd
>/usr/local/ldm/data/gempak/gfs
> [ldm@eurus gfs]$ ls -al
>total 111040
>drwxr-xr-x 2 ldm gempak 4096 Feb 15 16:55 .
>drwxrwxr-x 11 gempak gempak 4096 Feb 15 15:28 ..
>-rw-r--r-- 1 ldm gempak 23822157 Feb 15 16:45 2006021518f0000.onedeg
>-rw-r--r-- 1 ldm gempak 26754696 Feb 15 16:51 2006021518f0003.onedeg
>-rw-r--r-- 1 ldm gempak 26822270 Feb 15 16:55 2006021518f0006.onedeg
>-rw-r--r-- 1 ldm gempak 25093044 Feb 15 16:57 2006021518f0009.onedeg
>-rw-r--r-- 1 ldm gempak 11047070 Feb 15 16:57 2006021518f0012.onedeg
> These are not decoded files, but the raw files, so these cannot be used in
>garp, right?

Correct. The grib files won't be usable until decoded. The decoder uses the 
grib identification tables
to convert the numbers in the grib data to parameters, levels, times etc.
The output from dcgrib2 should be in ~ldm/data/gempak/model/gfs, which is not 
the same directory
as you specified for the raw grib output.

To view the data, if its there:
Try NMAP2. Launch the program and pull up the data selection widget
(http://www.unidata.ucar.edu/software/gempak/tutorial/nmap_data.html)

Select "New Source" and click on the "GRID" label. That will provide a list
of models. Scroll down the models to gfs003, then select the run time
such as 060215_1800 using your output below.

A quick plot example:
select the A1.standard menu,
then select 500mb_HGHT_ABSV
folowed by accept.

The time widget will show 61 forecast times (f000-f180) select "LOAD".

As for the LDM product queue, if you are a leaf node, the queue only needs to 
be large enough to hold
data long enough for pqact to process it! If your machine screams, then 10 
minutes would be fine.
If your decoding etc is slower, you want a larger queue so that the data isn't 
scoured out before pqact
gets around to it. Nothing in GEMPAK depends on the size of your product queue 
directly. It just
controls the buffering available while your decoders etc are chewing on all 
that data!

If you are sending data to other LDM's, then you typically want a queue large 
enough to hold
the amount of data ytou typically receive in 1 hour.


Steve Chiswell
Unidata User Support

Ticket Details
===================
Ticket ID: GUX-304848
Department: Support GEMPAK
Priority: High
Status: Closed