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

[GEMPAK #GUX-304848]: GEMPAK and GARP


> This is what I did....I then did clean and rebuilt the distribution, and I
> didn't get any errors, so I think things were okay.
> 
> That said, I guess I feel like an idiot, but I can't see how I am supposed to
> start Garp, or any other gui for that matter (I have looked at lots of online
> material, and they all seem to assume that you know how to start the gui, and
> just begin with having it running and go forward from there.  Help?

Jennie,

If you have built and installed the distribution, so that the GUI programs
(ntl, nmap2, nwx, etc) are in the $GEMEXE directory, you can run them either by
running "ntl" and then clicking on the gui icon for the particular program,
or just run the program itself, such as "nmap2". If the GUI programs are not
in $GEMEXE, did you run "make install"? 





> 
> 
> 
>
> 
> Okay, I have modified to just get the onedeg grids as noted, and I started the
> ldm with the following Request line
> 
> REQUEST NMC2 ".*" idd.unidata.ucar.edu:388  #initial-primary host
> 
> after building a queue (I presume the default size is large enough?)

The default queue size is too small (if you are using a 400mb queue).
The 1 degree grids will be about 1.3 GB per run, and assuming you have
other data you want to receive by IDD, you probably want to be running
a 2GB queue (or at least 1.2GB).


> 
> I can see that products are arriving with the ldmadmin watch command
> 
> Feb 15 16:39:46 pqutil INFO:    51600 20060215160522.449 CONDUIT 304
> /afs/.nwstg.nws.noaa.gov/ftp/SL.us008001/ST.opnl/MT.gfs_CY.12/RD.20060215/PT.grid_DF.gr1/fh.0072_tl.press_gr.onedeg
> !grib/ncep/AVN/#003/200602151200/F072/PEVPR/sfc! 000304
> 
> Then I also tried to have a pqact that would file the GFS raw grib files that
> come in to a directory /met/data/gempak/GFS
> 
> CONDUIT MT.gfs*PT.grid_DF.gr1*fh.*_tl.press_gr.onedeg
> FILE    /met/data/gempak/GFS/
> 
> Is there something wrong with this?
> Maybe I should just be using data/gempak/GFS, since I have a runtime link from
> the local directory data (for user ldm) that is runtime linked to /met/data?


The FILE action above has no output file name to place your data into. If
you want to store the GRIB data onto disk, then you want something like:

CONDUIT     MT.gfs_CY.(..)/RD.(........)/.*/fh.(....)_tl.*onedeg
     FILE   data/grib/gfs/\2\1f\3.onedeg


> 
> But so far, nothing has been filed there?
> 
> Finally, if I want to decode these raw files (recall, I have two uses, the
> first one
> will use the raw grib files with some NASA code that will read a directory of
> these files and construct a new binary grid file for my use in running a large
> trajectory model;  the other use is to be able to use Gempak to plot up data,
> or make cross sections, from these model grids, so I need to have them 
> decoded)
> 
> I was going to run a command like:
> #CONDUIT        MT.gfs*PT.grid_DF.gr1*fh.*_tl.press_gr.onedeg
> #       PIPE    /home/gempak/GEMPAK5.9.1/oz/linux/bin/dcgrib2
> but now I see that it should be constructed as:
> 
> #CONDUIT        MT.gfs*PT.grid_DF.gr1*fh.*_tl.press_gr.onedeg
> #       PIPE    decoders/dcgrib2 -d 
> met/data/gempak/logs/dcgrib2_CONDUITgfs.log
> #       -e GEMTBL=/home/gempak/GEMPAK5.9.1/gempak/tables
> 
> since I have to tell it where the gribkey.tbl file is located

Yes, or even
CONDUIT        MT.gfs.*onedeg
    PIPE       ......etc
> 
> > The dcgrib2 decoder will decode either GRIB1, or GRIB2, so you don't have to
> > differentiate that in your pattern. Also, the dcgrib2 program will decode 
> > the
> > data to the location specified in $GEMTBL/grid/gribkey.tbl (which is the
> > data/gempak/model/gfs/YYYYMMDDHH_gfs003.gem entry). The $MODEL environmental
> > variable defined in Gemenviron will point to your LDM's data/gempak/model
> > directory.
> 
> 
> Meaning this entry under gfs:?
> 007   x   077,81,96 003    data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem   29000

Correct!

> 
> Since I didn't read all this before I set up the ldm, I have my data directed
> to
> /met/data/gempak
> 
> but, since its the ldm that runs these commands, then the local directory data
> is runtime linked to /met/data , so this will all be okay, right?

Yes....if your ~ldm/data is linked to /met/data, then your data will get 
decoded there,
and in your Gemenviron file, you will want to define GEMDATA as /met/data/gempak
(the defaults setting is /data/ldm/gempak in the Gemenviron file).

Steve Chiswell
Unidata User Support


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