[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030612: FW: GRIB



>From:  Matthew Lazzara <address@hidden>
>Organization:  SSEC 
>Keywords:  200306121920.h5CJKMLd002357 McIDAS GRIBDEC AMPS

Hi Matthew,

re:

>3.  Tom Yoksas at Unidata and Kevin - we have one problem, and I'm not 
>clear if the problem is with the GRIB coding or with the McIDAS 
>converter software (GRIBDEC).  The forecast runtime & day is being set 
>to the forecast validtime & day in the McIDAS GRID files that are being 
>created.  This makes for a mess with the number of GRID files created (I 
>ought to have 1 file per day per domain for the model output in McIDAS, 
>I've got several).  This problem will make it hard to keep a series of 
>AMPS runs available via ADDE.  Tom - can you help isolate where this 
>problem is so either you/I can tackle it in GRIBDEC or if the problem is 
>with the GRIB files we can have Kevin patch it up??  Tom, please let me 
>know if you don't have time to look into this at all..
>Hi!  I'm finally replying to you about this...and yes, I'm now "using" 
>them.  I've setup something that grabs the AMPS GRIB data and converts 
>it into McIDAS GRID files.  For those on the CC list of this e-mail, the 
>data is available via the ADDE dataset: AMRC on the workstation/server 
>ice.ssec.wisc.edu (in McIDAS-X type DATALOC ADD AMRC ice.ssec.wisc.edu 
>and then run a DSINFO G AMRC and GRDLIST AMRC/AMPS FORM=FILE ALL to see 
>the one model run that I do have there now). I do have the following 
>questions and concerns for a few different folks:

My initial inclination is that there is not because the code mods I
made for the GRIBDEC bundle have been incorporated into the McIDAS-XCD
core and are being used at a variety of sites to decode all of the grib
data in the NOAAPORT broadcast.  Also, the folks at JSC are using my
latest GRIBDEC bundle to decode model data they grab by FTP from the
NWS.  It seems to me that if there was something as seriously wrong
with the code as you are reporting, then someone else would have
noticed it also.

Please give me access to one or more files of grib data for which you
see this problem and I will check to see if there is anything in the
GRIBDEC code that could be causing it.

Cheers,

Tom

>1.  Kevin - I'm going to get the data from the web site at 4 UTC (for 
>the 0 UTC run) and 16 UTC (for the 12 UTC run).  Does that sounds like 
>good times to ensure getting the full forecast run?
>
>2.  Kevin and folks at SPAWAR - I'm only going to grab data from 
>forecast hours 0,3,6,9, etc. up to 72 hours for each of the "D1", "D2", 
>etc. domains.  I notice that you offer different forecast hours for 
>different domains.  I'm not sure what folks want, but perhaps the SPAWAR 
>folks can comment on that here.
>
>3.  Tom Yoksas at Unidata and Kevin - we have one problem, and I'm not 
>clear if the problem is with the GRIB coding or with the McIDAS 
>converter software (GRIBDEC).  The forecast runtime & day is being set 
>to the forecast validtime & day in the McIDAS GRID files that are being 
>created.  This makes for a mess with the number of GRID files created (I 
>ought to have 1 file per day per domain for the model output in McIDAS, 
>I've got several).  This problem will make it hard to keep a series of 
>AMPS runs available via ADDE.  Tom - can you help isolate where this 
>problem is so either you/I can tackle it in GRIBDEC or if the problem is 
>with the GRIB files we can have Kevin patch it up??  Tom, please let me 
>know if you don't have time to look into this at all..
>
>
>Once we get the final kinks worked out, I hope to grab the data 
>routinely, post it on our ADDE server for the McIDAS community, and post 
>displays to our web site - if there are no objections from anyone.  We 
>will give full credit and web links to the AMPS folks, of course.
>
>Comments, concerns welcome....
>
>Thanks all!!
>
>Matthew
>
>
>Kevin Manning wrote:
>> Matthew, et al.,
>> 
>> Maybe it's a little premature (since nobody's been using them yet),
>> but we've started to put GRIB files from the real-time AMPS run on our
>> web page, under directory:
>> 
>>   http://box.mmm.ucar.edu/rt/mm5/amps/grib/
>> 
>> These are pretty much the same fields as in the test files, one file
>> for each forecast hour and each model grid.
>> 
>> So you might want to try your McIDAS converters on some of those
>> files.
>> 
>> --Kevin
>> 
>> Matthew Lazzara writes:
>>  > 
>>  > Art and Bob,
>>  > 
>>  > Hello!  I've been remiss in putting these grib files into use for you to 
>>  > trial with McIDAS.  They are now available at the following ADDE dataset:
>>  > 
>>  > AMPS/SAMPLE on ice.ssec.wisc.edu
>>  > 
>>  > (so in McIDAS type: DATALOC ADD AMPS ICE.SSEC.WISC.EDU - then check out 
>>  > the dataset using DSINFO G AMPS and GRDLIST AMPS/SAMPLE FORM=FILE ALL)
>>  > 
>>  > I don't think I have the best configuration of the data in the dataset - 
>>  >   its just following along with the way Tom Yoksas's code handles it 
>>  > (and I keep it in multiple files for use...but in one dataset).  We may 
>>  > want a dataset for each forecast hour... (I've yet to play with the data 
>>  > myself!)  In any case, it is out there, and a few tests worked great.
>>  > 
>>  > Cheers,
>>  > 
>>  > Matthew
>>  > 
>>  > P.S. Bob - if you are in need of some GRDDISP command ideas on to 
>>  > show/display the data to Art and the gang, let me know, and I'll dream 
>>  > up some for you...
>>  > 
>>  > 
>>  > Cayette, Arthur Spawar wrote:
>>  > > Not sure if you would like these too, but here they are.
>>  > > 
>>  > > Art
>>  > > 
>>  > > -----Original Message-----
>>  > > From: Kevin Manning [mailto:address@hidden
>>  > > Sent: Tuesday, May 06, 2003 4:33 PM
>>  > > To: Vehorn, Robert Spawar; Cayette, Arthur Spawar
>>  > > Subject: RE: GRIB
>>  > > 
>>  > > 
>>  > > Bob, Art:
>>  > > 
>>  > > Got some sample GRIB files for you.  Look in 
>>  > > 
>>  > >     http://box.mmm.ucar.edu/rt/mm5/amps/test/grb
>>  > > 
>>  > > I've only processed grid 2, the 30-km grid, so around McMurdo, things
>>  > > could look a little funky because of feedback from the deeper nests.
>>  > > 
>>  > > These files have pressure-level u, v, T, Hgt, R.H., Q_vapor, Q_cloud,
>>  > > Q_rain, Q_ice, Q_snow; 10-m u, v; 2-m T, Q_vapor, R.H.; accumulated
>>  > > rain from convective and explicit schemes, terrain elevation, surface
>>  > > sensible and latent heat fluxes; downwelling longwave and shortwave
>>  > > radiation fluxes at the surface.
>>  > > 
>>  > > Pressure levels are 1000,925,850,700,600,500,400,300,250,200,150,100.
>>  > > 
>>  > > These files were generated with my home-grown GRIB encoding routines.
>>  > > I think I'm conforming to the GRIB Edition 1 format, but I wouldn't be
>>  > > surprised if somewhere along the way we run into non-conforming
>>  > > pieces.  Let me know if you find that, because I'd like to conform.
>>  > > 
>>  > > I think my code numbers are consistent with NCEP usage.  Variables are
>>  > > output on the original model grid in the horizontal.  Since MM5 uses a
>>  > > staggered grid, the u and v arrays are one larger in each dimension
>>  > > than the other arrays.  There's a half-point offset in the grid
>>  > > locations between the velocities and the other variables.  The grid
>>  > > description section in the GRIB records reflects that offset, with
>>  > > slightly different grid definitions for velocities vis-a-vis the other
>>  > > variables.
>>  > > 
>>  > > There are a number of other issues we may have to work through: how
>>  > > humidity is handled, how to assign pressure level data below ground,
>>  > > whether we're saving enough precision (or keeping too much) in the
>>  > > GRIB packing, other variables, other levels, etc.  We can certainly
>>  > > address more of these as we go along.  And the issues we run into
>>  > > probably differ when we move to the other resolutions.
>>  > > 
>>  > > Let me know how it works out for you.
>>  > > 
>>  > > --Kevin
>>  > 
>>  > 
>>  > -- 
>>  > ------------------------------------------------------------------------
>>  > Matthew Lazzara -Meteorologist- Antarctic Meteorological Research Center
>>  > 947 Atmospheric, Oceanic and Space Sciences    http://amrc.ssec.wisc.edu
>>  > Space Science and Engineering Center         E-mail: address@hidden
>>  > University of Wisconsin-Madison                    Phone: (608) 262-0436
>>  > 1225 West Dayton Street, Madison, WI 53706           Fax: (608) 263-6738
>>  > ------------------------------------------------------------------------
>
>
>-- 
>------------------------------------------------------------------------
>Matthew Lazzara -Meteorologist- Antarctic Meteorological Research Center
>947 Atmospheric, Oceanic and Space Sciences    http://amrc.ssec.wisc.edu
>Space Science and Engineering Center         E-mail: address@hidden
>University of Wisconsin-Madison                    Phone: (608) 262-0436
>1225 West Dayton Street, Madison, WI 53706           Fax: (608) 263-6738
>------------------------------------------------------------------------
>
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.