Samuel,
The feed request lines for CONDUIT that you show below do not subset the
data by region. Rather, they split the total volume of products over a
number
of LDM processes which can improve throughput on slow connections if
you experience latency using a single request pattern.
The LDM is not capable of subsetting autonomous GRIB products into
subregions,
so that is not an option with the CONDUIT feed. At this time, none of
the data products on CONDUIT are regional tiles. The GFS data is sent on
global high
resolution grids in the CONDUIT data stream.
The NGRID data stream provides the products sent on the NWSTG2 NOAAport
channel, and does provide the GFS on a 40km US (CONUS) grid #212. It may
be
that this data set would satisfy your needs so that you don't have to
obtain the
global GFS grids via CONDUIT which are quite large. The following
pattern
(distributed with GEMPAK) will match the GFS CONUS 40km #212 grids
in the NGRID data stream:
# GRIB2 GFS
# AWIPS grids
# Grid #212 CONUS 40km: ^[LM].R... KWBC
NGRID ^[LM].R... KWBC
PIPE decoders/dcgrib2 -m 20000 -d
data/gempak/logs/dcgrib2_GFS2conus.log
-e GEMTBL=/home/gempak/NAWIPS/gempak/tables
data/gempak/model/gfs/YYYYMMDDHH_gfs212.gem
In regard to your CONDUIT request pattern of MT.gfs, that is not the
correct pattern to match the GFS data on CONDUIT (The MT.gfs file names
originated from the
NWS ftp servers and were eliminated over a year ago). The file name
conventions for GFS data on CONDUIT are provided here:
http://www.unidata.ucar.edu/data/conduit/ldm_idd/gfs_files.html
A general request line for GFS data on CONDUIT could be:
request CONDUIT "nccf/com/gfs" upstream_idd_host
If you determine that you need the GLOBAL high resolution data on
CONDUIT,
please contact support-conduit@xxxxxxxxxxxxxxxx an I can help you tailor
a
request line to fit your needs.
Steve Chiswell
Unidata User Support
On Thu, 2007-10-18 at 10:01 -0400, Zehel, Samuel wrote:
Iÿm trying to limit our LDM to ingest CONDUIT data from only the
Northeastern part of the U.S., however Iÿm not certain what regular
expression I should use. I notice the documentation talks about grid
numbers, but I canÿt seem to find any documentation on the actual
values of these numbers, or what group of numbers would be considered
the Northeast U.S.
I donÿt have a strong background in meteorology, so perhaps thatÿs my
problem, but surely someone has already done this.
Iÿve noticed that some people use the following REQUEST statements in
their ldmd.conf file:
request CONDUIT ´[09]$¡ host.domain.org
request CONDUIT ´[18]$¡ host.domain.org
request CONDUIT ´[27]$¡ host.domain.org
request CONDUIT ´[36]$¡ host.domain.org
request CONDUIT ´[45]$¡ host.domain.org
I know this divides CONDUIT into 5 separate data channels, but is this
limiting CONDUIT to a certain region? If so, what numbers would I
use for the Northeast? Would it even make sense to limit CONDIUT to
a region?
I know that conduit contains several products, and currently weÿre
ingesting the GFS set with the following entries is our ldmd.conf
file:
REQUEST CONDUIT "MT.gfs_CY.*[05]$" ourprimaryhost.domain.org
PRIMARY
REQUEST CONDUIT "MT.gfs_CY.*[05]$" idd.cise-nsf.gov ALTERNATE
REQUEST CONDUIT "MT.gfs_CY.*[16]$" ourprimaryhost.domain.org
PRIMARY
REQUEST CONDUIT "MT.gfs_CY.*[16]$" idd.cise-nsf.gov ALTERNATE
REQUEST CONDUIT "MT.gfs_CY.*[27]$" ourprimaryhost.domain.org
PRIMARY
REQUEST CONDUIT "MT.gfs_CY.*[27]$" idd.cise-nsf.gov ALTERNATE
REQUEST CONDUIT "MT.gfs_CY.*[38]$" ourprimaryhost.domain.org
PRIMARY
REQUEST CONDUIT "MT.gfs_CY.*[38]$" idd.cise-nsf.gov ALTERNATE
REQUEST CONDUIT "MT.gfs_CY.*[49]$" ourprimaryhost.domain.org PRIMARY
REQUEST CONDUIT "MT.gfs_CY.*[49]$" idd.cise-nsf.gov ALTERNATE
I believe this reduces our CONDUIT ingestion to a global subset, is
that right?
Iÿve also noticed that some people use NGRID with GFS, is this
necessary, or simply a good idea?
Iÿve been bugging the heck out of Unidata Support (Thank you for being
patient with me Tom Yoksas), and trying to glean hints from the
support archives, but I think Iÿm out of ideas. Any help would be
greatly appreciated.
Samuel M. Zehel Jnr
Applications Programmer I
California University of Pennsylvania
250 University Ave
California PA 15419
Office: Eberly Science 271
724-938-1582
mailto:zehel@xxxxxxx
_______________________________________________
ldm-users mailing list
ldm-users@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
--
Steve Chiswell <chiz@xxxxxxxxxxxxxxxx>
Unidata
