This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
All,These email exchanges really beg the question of, "when are you planning to move to Grib2?" What are the barriers preventing you to make this change?
If you recall, a CONDUIT survey was conducted last August and 9 responses indicated they could handle GRIB2, with 4 indicating they could not. I note that Brent responded this morning with information on converters. This has also been available at NWS for some time now.
Please note the C2 summary from the January meeting in San Diego last month. There is momentum to move forward with additional data sets, and we want you to benefit by this action. As long as we continue to provide duplications of essentially the same datasets, due to GRIB and GRIB2 issues, it will inhibit moving forward.
<http://my.unidata.ucar.edu/content/Projects/CONDUIT/C2.summary.1.05.html> Thanks for listening! Linda--On Friday, February 04, 2005 9:32 AM -0800 David Ovens <address@hidden> wrote:
CONDUIT folks, I think Pete Pokrandt has summed up all of my (U.Wash Atm. Sci.) votes, concerns, and questions quite well. Ditto. -- David Ovens e-mail: address@hidden Research Meteorologist phone: (206) 685-8108 Dept of Atm. Sciences plan: Real-time MM5 forecasting for the Box 351640 Pacific Northwest University of Washington http://www.atmos.washington.edu/mm5rt Seattle, WA 98195 Weather Graphics and Loops http://www.atmos.washington.edu/~ovens/loops On Fri, Feb 04, 2005 at 11:12:41AM -0600, Pete Pokrandt wrote:In a previous message to me, you wrote: > Pete, > > There are several options that feed back from the users would be helpful > in moving forward: Steve, Thanks for getting back to me on this so quickly. My thoughts below: > > One pending action item from Last June was to remove the ETA > awip20 (grid 215) files when ETA218 was available. Does anyone > rely on these files from CONDUIT? Would the ETA218 grids in > NOAAPORT (GRIB2 format in DVB-S) eliminate the need for > grid 215 in CONDUIT? We (UWisc-AOS) could definitely live w/o the 215 grids. We're currently not using them at all. That doesn't really reduce the data stream all that much though, compared to the increase from the 0.5 deg GFS, does it? > > As an alternative to removing the 0.5 degree GFS, would it be useful > to keep the highest resolution grids available for f000-f084 and > remove the 1 degree grids for the period of time where the two sets > overlap? This is a good idea, however I suspect many of us are using software that does not yet read the GRIB2 format files. How easy or hard would it be to come up with a conversion utility that would read the 0.5 deg grib2 data and convert into either 0.5 deg GRIB (with similar format, parameters that we currently have) or to average out to a 1 deg format in the same format as the current 1 deg files? Is this even feasible? > > There are a number of data sets which users have expressed interest > in adding, though clearly it is not advisable to be adding with the > current limitations. I agree, adding anything at this point would only make things worse. Would having multipile ingest boxes, each doing different parts of the conduit feed make any difference, or would that just pass the delay and backlog downstream to the top level relays? How about another "experimental" conduit feed, or one for new, or GRIB2 formatted data that the new data could be tested on without any expectation of regular timely delivery? I guess CONDUIT does not 'guarantee' timely delivery, but it has been so reliable over the past couple of years that many of us have come to depend on the products in it, and pretty much expect it to be reliable. It seems to me that the problem we are seeing, or trying to get around, is that there are short periods where LOTS of data becomes available, and while we'd all like to get the data as soon as it is available, the current latency of the network and/or ldm is just not capable of handling the large bursts in a reliable and predictable manner. My rambling thoughts.. Personally, I'd still vote to remove the 0.5 deg gfs data from the CONDUIT stream for now.. Pete > > Steve Chiswell > Unidata User Support > > On Fri, 4 Feb 2005, Pete Pokrandt wrote: > >> >> All, >> >> 06 UTC GFS didn't start coming in here until after 12 UTC this AM. >> It's just now finishing up at 14:31 UTC. >> >> I'd like to second Robert's suggestion from a few weeks ago that >> we back out of the 0.5 deg GFS data until we can resolve these >> speed issues. >> >> I haven't had time to even look at the 0.5 GFS data yet; is anyone >> using it? >> >> Pete >> >> -- >> +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+ >> ^ Pete Pokrandt V 1447 AOSS Bldg 1225 W Dayton St^ >> ^ Systems Programmer V Madison, WI 53706 ^ >> ^ V address@hidden ^ >> ^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^ >> ^ University of Wisconsin-Madison V 262-0166 (Fax) ^ >> +<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+ >> -- +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+ ^ Pete Pokrandt V 1447 AOSS Bldg 1225 W Dayton St^ ^ Systems Programmer V Madison, WI 53706 ^ ^ V address@hidden ^ ^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^ ^ University of Wisconsin-Madison V 262-0166 (Fax) ^ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
Linda Miller - address@hidden Community Services, Unidata University Corporation for Atmospheric Research P.O. Box 3000 Boulder, CO 80307-3000 303-497-8646 fax: 303-497-8690