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