NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

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

I would agree that full vertical res on the GFS would be fantastic.
Also have to agree on the uselessness of the RTMA. Surely meteorologists aren't replacing their own mesoanalysis with that..we certainly don't. 

Robert


-----Original Message-----
From: conduit-bounces@xxxxxxxxxxxxxxxx on behalf of Jim Bresch
Sent: Sun 10/26/2008 10:34 PM
To: conduit@xxxxxxxxxxxxxxxx
Cc: support-conduit@xxxxxxxxxxxxxxxx
Subject: Re: [conduit] [CONDUIT #DYD-390666]: 20081022: follow-up to 
Unidata User's Committee CONDU IT survey

   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.

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