Re: [conduit] [CONDUIT #DYD-390666]: 20081022: follow-up to Unidata User's Committee CONDU IT survey

  • To: conduit@xxxxxxxxxxxxxxxx
  • Subject: Re: [conduit] [CONDUIT #DYD-390666]: 20081022: follow-up to Unidata User's Committee CONDU IT survey
  • From: Jim Bresch <bresch@xxxxxxxx>
  • Date: Sun, 26 Oct 2008 21:34:39 -0600
I use the 40 km as well. I thought the point of CONDUIT was to deliver NCEP NWP products to the users as quickly as possible. I am willing to trade lower resolution (40 vs 12 km) in order to acquire and process the output faster. I don't know the time difference between NOAAPORT and CONDUIT, but the time lag between CONDUIT and ftp is significant.

I also don't see the point in replacing a 5 Mb per output-time grid (212) with a 30 Mb per output-time grid (218). Why not keep both? Does the higher resolution justify the 6x increase in bandwidth and users having to redo all their scripts? Not in my view.

In order to determine what should be on CONDUIT, you need to know the maximum CONDUIT bandwidth, what output files people are currently using, and what files are being downloaded from the NCEP ftp site.

I have no need for SREF and what little I've seen of RTMA has been garbage. I'd much rather have the native-grid .325 GFS with full vertical resolution.


Gary Lackmann wrote the following on 10/26/08 8:37 PM:
Hi Kevin and Mike,

We also use the 40-km NAM 212 grid, but it does not come through the CONDUIT feed. The reason for possible elimination of this grid on CONDUIT was that it was duplicated between the feeds (NOAAPORT and CONDUIT). However, if there are differences, such as a higher top or additional fields in the CONDUIT feed, please let us know.

Kevin W. Thomas wrote:

Tom and CONDUIT Community,

Am I the only one who depends on the NAM 40 KM stuff? This is the "awip3d" I believe. Most of our outreach/teaching visualization is based on this grid. In addition, I relay to the NAM212 to a downstream site, which depends on it.

No, you aren't the only one.

I run four hourly analyses on older equipment.  It takes too long for the
software that I use to process the 12km data files, so I've had to stay
around with the 40km.

This means that I'll have to ftp the 40km data along with all the rest of the
NAM data that I use.  It looks like the CONDUIT data stream is no longer
meeting my needs.

Also, which _current_ CONDUIT grid could be used in place of the NAM212? My NAM218 (awip12) does not have the vertical levels. I guess the available NAM 12 KM grids will be expanded to include the vertical levels at the same time the NAM 40 KM is removed. My concern is bandwidth, storage, processing time.....and the fact that I do not have a chance to migrate my scripts to the new grid until it's here. Will there be an overlap period?

I certainly hope that the vertical levels will be added. If not, NAM data
on CONDUIT will be a waste of time with the removal of the 40km data.

Anyhow, I thought I would throw in my .02 cents in case it's not to late, or in case others have the same concerns.



    Kevin W. Thomas
    Center for Analysis and Prediction of Storms
    University of Oklahoma
    Norman, Oklahoma
    Email:  kwthomas@xxxxxx

At 03:14 PM 10/22/2008, Unidata CONDUIT Support wrote:
Users of the IDD CONDUIT datastream:

This email is being sent on behalf of the Unidata Users's Committee.

Compilation of responses to the Unidata User's Committee spring 2008 survey on CONDUIT datastream deletions/additions showed consensus for the following changes
to the datastream:


- 40 km NAM CONUS (NCEP offering to provide 12 km, 60 levels, 84 hours at 0,6,12,18Z)
- 2.5 degree MRF out to 168 hours


- RTMA -- Real Time Mesoscale Analysis
- SREF -- Short Range Ensemble Forecast

Based on the survey results, we will be working with NCEP to make the following changes to CONDUIT _before_ the annual holiday moratorium on changes to the CCS Production Suite (currently scheduled for Wednesday, 17 December 2008, but changes must be requested
before Monday, 20 November):

1) remove the 40 km NAM and 2.5 degree MRF products from CONDUIT

2) add SREF data to CONDUIT

3) add the parallel run (non-operational) RTMA grids to CONDUIT (since the operational
  RTMA products are already available in the IDD; see below)

Please let us know as soon as possible if any of these changes will significantly impact
your use of data delivered in CONDUIT.

Comments on the availability of operational RTMA grids:

- a review of NWS TECHNICAL IMPLEMENTATION NOTICE announcements broadcast in NOAAPort:

and sent to subscribers of the nws-changes@xxxxxxxxxxxxxxxx email list:

reminded us that a number of operational RTMA grids have been included in the NOAAPort satellite broadcast and in the IDD NGRID datastream since the end of summer, 2006.

 The RTMA fields currently included in NGRID are:

 2 m Temperature and Temperature error
 2 m Dewpoint temperature and dewpoint temperature error
 10 m U wind component
 10 m V wind component
 10 m wind Direction and Direction error
 10 m wind Speed and Speed Error
 Precipitation /no error grid/
 GOES effective cloud amount /no error grid/

A full listing of what is available can be generated using the 'notifyme' invocations
 listed below.

- a LDM 'pqact' pattern-action entry for some of the RTMA grids that are available in the IDD NGRID datastream is contained in the Unidata GEMPAK v5.11.1 (and several previous)

Please review the information in the 'Site Configuration for Products' portion of the Unidata GEMPAK website for instructions on how to create LDM pattern-action
 file(s) and 'ldmd.conf' entries:

 Unidata HomePage

  Unidata GEMPAK HomePage

    Site Configuration for Products

The Unidata GEMPAK 5.11.4 release (which is being prepared now) will contain updated pattern(s) to process the RTMA grids in the IDD NGRID datastream.

- NOTE: for sites not using GEMPAK or the GEMPAK LDM pattern action files:

- request the RTMA grids via an ldmd.conf entry for the NGRID datastream:

request NGRID "RTMA" upstream_feed_host <- replace 'upstream_feed_host' with the name of an LDM server that provides NGRID

- use the LDM 'notifyme' utility to verify that your upstream and your own LDMs are receiving the RTMA products from NGRID (in both cases 'notifyme' is run as user 'ldm'):

notifyme -vxl- -f NGRID -o 10000 -p RTMA -h upstream_feed_host

Your own LDM:
notifyme -vxl- -f NGRID -o 10000 -p RTMA

- example 'pqact' pattern-action file entries that will FILE the non-cloud amount and precipitation RTMA products into different directories based on their grid
   (e.g., grid 175, 201, 213, 227):

# RTMA (real-time mesoscale analysis) grids
NGRID   RTMA/#(.*)/(............)F.../(.*)/(.*) m HGHT
       FILE  data/rtma/\1/\2_\3.\4m

Example 'pqact' pattern-action file entries that will FILE the RTMA GOES
   effective cloud amount and precipitation products:

# RTMA (real-time mesoscale analysis) cloud amount and precipitation grids
NGRID   RTMA/#(.*)/(............)F.../(.*)
       FILE  data/rtma/\1/\2_\3

Please remember that some whitespace in 'pqact' patterns are tabs, not spaces:

   whitespace between NGRID and RTMA is a tab
   whitespace before FILE is a tab
   whitespace after FILE is a tab


**************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 support@xxxxxxxxxxxxxxxx Boulder, CO 80307 ----------------------------------------------------------------------------
Unidata HomePage             

conduit mailing list
For list information or to unsubscribe, visit:
Mike Voss
Department of Meteorology
San Jose State University
One Washington Square
San Jose, CA 95192-0104

408.924.5204 voice
408.924.5191 fax _______________________________________________
conduit mailing list
For list information or to unsubscribe, visit:
conduit mailing list
For list information or to unsubscribe, visit:

conduit mailing list
For list information or to unsubscribe, visit:

  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the conduit archives: