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

20051005: 20051003: pqact template for GFS conduit data

John,

The provided pqact.conf action for MT.gfs is correct for grid #2 and #3:
CONDUIT ST.opnl/MT.gfs
        PIPE    decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs.log
        -e GEMTBL=/home/gempak/NAWIPS/gempak/tables

The program dcgrib2 will determine the maximum number of grids for the file
from the $GEMTBL/grid/gribkey.tbl (where GEMTBL above is specified for
your site location).

The -m flag is used when not using gribkey.tbl to determine the output file 
names.

What are your ldmd.conf request lines?

Steve Chiswell
Unidata User SUpport




>From: "John Hobbie" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200510051844.j95IiGG7000363

>Hi Steve --
>
>I looked up the pqact template that was on an old backup file and found, 
>CONDUIT    MT.(avn|gfs|mrf|ensg)
>        PIPE    decoders/dcgrib2 -m 22999 -d data/gempak/logs/dcgrib_nmc2.log
>        -e GEMTBL=/home/gempak/NAWIPS/gempak/tables
>
>I wasn't sure about the  -m option  -- there seem to be two possible uses for 
> it ,  maxtime and maxgrids --  but should that be increased in size, and if s
> o, by how much?   And also should I use that version of the template?
>
>The other thing I discovered was that there is a difference in the  dcrib_nmc2
> .log s in the two systems -- the older gempak/ldm on "newpsn.nsbf.nasa.gov" a
> nd the latest gempak/ldm on "psnldm.nsbf.nasa".   The  system with the older 
> gempak version consistenly list 25619 files read and processed.  The new syst
> em logs anywhere from 9164 to 11666 files.
>
>Also, the system with the older gempak/ldm versions   gets the full forecast t
> ime run (180 hrs for GFS003 and out to 384 hours for GFS002)  but the box wit
> h the new gempak/ldm version rarely gets past 90 hours and doesn't generate  
> GFS002.
>
>Could this be due to a configuration problem of too many open files or insuffi
> cient allocated memory?  If so, what do you recommend   as a fix?
>
>Could it be a difference in decoders between the older gempak version and the 
> latest?  If so, shoud I swap the one that works for the one that is having pr
> oblems? 
>
>Our operating plan is to make the upgrades as easy to perform as possible.   T
> hus, with each new issue of gempak, the latest decoders are put in the ldm' s
>  decoder directory and the latest pqact.gempak file  is used to replace the c
> omparable entries in the existing pqact.conf file.   The idea is to accept wh
> at unidata sends out as the default pqact to minimize the need for tweeking, 
> thus reducing the level of computer knowlege required to affect the upgrade. 
>  
>
>Thanks for any ideas you might have on this,
>
>Hobbie
>
>-----Original message-----
>From: Unidata Support address@hidden
>Date: Tue,  4 Oct 2005 14:48:25 -0500
>To: "John Hobbie" address@hidden
>Subject: 20051003: pqact template for GFS conduit data
>
>
>John,
>
>All current GEMPAK templates and decoders work. 
>The entries below will capture the grid #002 and grid #003 from the ST.opnl
>line, as well as the grid #004 (0.5 degree) from the ST.opnt line.
>All three data sets are being decoded here.
>
>Check your ldmd.conf on your new machine and verify that it is asking
>for the grid #003 GFS in its request to your old machine.
>
>I don't see that nsbf is sending any LDM stats, so I can't verify the volume 
>of data that your new macine is seeing.
>
>Steve Chiswell
>Unidata USer Support
>
>
>
>
>
>>From: "John Hobbie" <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200510032153.j93LreG7003123
>
>>Hi--
>>
>>I recently installed the latest GEMPAK, and LDM on one machine, while another
>  
>> machine is still running several previous versions ago software.  The old sy
> s
>> tem is feeding the new system the conduit GFS products from thelma.  The old
>  
>> system is capturing and decoding the GFS002 data (the global extended out to
>  
>> 384 hours) as well as the GFS003 data (the global hi res up to 10mb);  it du
> m
>> ps them both into a common directory called model along with other model dat
> a
>> .   The new system is only collecting the GFS003 data.
>>
>>We are using the latest pqact-gempak templates in the new system and the mode
> l
>>  data are being placed in directories by grid type -- ETA, GFS, NGM etc -- b
> u
>> t no GFS002 file is being generated.  I can not discern any differences in t
> h
>> e CONDUIT template in the two systems but I won't promise that I missed some
> t
>> hing.  
>>
>>Do the new pqact templates miss the GFS002 products?   Or are there new decod
> e
>> rs that are not properly decoding the GFS002 or renaming them to something e
> l
>> se and stuffing in an other directory other than gfs?  
>>
>>The pqact.conf entry being used on the new machine is:
>>
>>CONDUIT ST.opnl/MT.gfs
>>        PIPE    decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs.log
>>        -e GEMTBL=/home/gempak/GEMPAK5.8.3a/gempak/tables
>>#
>># Use a single dcgrib2 decoder for all 0.5 degree GFS data
>>CONDUIT ST.opnt/MT.gfs   
>>        PIPE    decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs2.log
>>        -e GEMTBL=/home/gempak/GEMPAK5.8.3a/gempak/tables
>>#
>>
>>Thanks for your help
>>
>>Hobbie
>>
>>National Scientific Balloon Facility
>>
>--
>NOTE: All email exchanges with Unidata User Support are recorded in the
>Unidata inquiry tracking system and then made publicly available
>through the web.  If you do not want to have your interactions made
>available in this way, you must let us know in each email you send to us.
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.