>From: Matthew Lazzara <address@hidden> >Organization: SSEC >Keywords: 200306121920.h5CJKMLd002357 McIDAS GRIBDEC AMPS Matthew, re: AMPS grib data decoded into McIDAS GRID always shows runtime & day being the same as valid time & day >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.. >The data I'm using is on the web site listed way below in the e-mails or >to bring it up here: > >http://box.mmm.ucar.edu/rt/mm5/amps/grib/ > >If you can't get it, let me know, and I'll get a set and leave it on an >ftp site for you to get. I grabbed three files from the web page you pointed me to. I want to make sure that I understand what the files in the various directories represent. http://box.mmm.ucar.edu/rt/mm5/amps/grib/ gave the list: 2003060600/ 06-Jun-2003 02:15 - 2003060612/ 06-Jun-2003 14:34 - 2003060700/ 07-Jun-2003 02:18 - 2003060712/ 07-Jun-2003 14:17 - 2003060800/ 08-Jun-2003 03:32 - 2003060812/ 08-Jun-2003 15:51 - 2003060900/ 09-Jun-2003 03:08 - 2003060912/ 09-Jun-2003 14:26 - 2003061000/ 10-Jun-2003 02:15 - 2003061012/ 10-Jun-2003 14:22 - 2003061100/ 11-Jun-2003 02:57 - 2003061112/ 11-Jun-2003 14:57 - 2003061200/ 12-Jun-2003 03:08 - 2003061212/ 12-Jun-2003 16:03 - 2003061300/ 13-Jun-2003 03:49 - Since the AMPS model is run twice daily, I take these entries to mean that they contain all output for the indicated model run year/month/day/time. Descending down into the 2003061300 directory, I see files that look like: 2003061300_d1_f00.grb 13-Jun-2003 00:00 1.7M 2003061300_d1_f03.grb 13-Jun-2003 00:00 2.6M 2003061300_d1_f06.grb 13-Jun-2003 00:09 2.7M ... 2003061300_d2_f00.grb 13-Jun-2003 00:07 4.9M 2003061300_d2_f03.grb 13-Jun-2003 00:07 7.3M 2003061300_d2_f06.grb 13-Jun-2003 00:07 7.3M ... 2003061300_d3_f06.grb 13-Jun-2003 00:08 949K 2003061300_d3_f07.grb 13-Jun-2003 00:08 1.0M 2003061300_d3_f08.grb 13-Jun-2003 00:13 1.0M ... 2003061300_d4_f06.grb 13-Jun-2003 00:08 879K 2003061300_d4_f07.grb 13-Jun-2003 00:08 938K 2003061300_d4_f08.grb 13-Jun-2003 00:13 945K ... 2003061300_d5_f06.grb 13-Jun-2003 00:08 1.2M 2003061300_d5_f07.grb 13-Jun-2003 00:08 1.2M 2003061300_d5_f08.grb 13-Jun-2003 00:13 1.3M I am interpreting the names of the files to mean: 2003061300 - model run time d1,...,d5 - domain of the grids f00,...,fnn - forecast times Is this correct? I observe that the Hour of Day (PDS word 16) which is part of the sequence: - Year of Century (PDS word 13) - Month of Year (PDS word 14) - Day of Month (PDS word 15) - Hour of Day (PDS word 16) - Minute of Hour (PDS word 17) varies by forecast time, but the: - Forecast Time Unit (PDS word 18) - P1 - period of time (PDS word 19) - P2 - period of time (PDS word 20) - Time Range Indicator (PDS word 21) do not: % ./gribdec.k ~/gribdata/2003061300_d1_f00.grb 6000 NUM=1 Year of Century = 3 Month of Year = 6 Day of Month = 13 Hour of Day = 0 <--- 0 Minute of Hour = 0 ConvertForecast:: Forecast Time Unit = 1 ConvertForecast:: P1 - Period of Time = 0 <--- 0 ConvertForecast:: P2 - Period of Time = 0 ConvertForecast:: Time Range Indicator = 0 Input GRIB file: /home/mcidas/gribdata/2003061300_d1_f00.grb Output GRID file: GRID6004 GRIB messages:: Found: 2 Decoded: 1 Written: 1 GRIBDEC: Done % ./gribdec.k ~/gribdata/2003061300_d1_f03.grb 6000 NUM=1 Year of Century = 3 Month of Year = 6 Day of Month = 13 Hour of Day = 3 <--- 3 Minute of Hour = 0 ConvertForecast:: Forecast Time Unit = 1 ConvertForecast:: P1 - Period of Time = 0 <--- 0 ConvertForecast:: P2 - Period of Time = 0 ConvertForecast:: Time Range Indicator = 0 Input GRIB file: /home/mcidas/gribdata/2003061300_d1_f03.grb Output GRID file: GRID6004 GRIB messages:: Found: 2 Decoded: 1 Written: 1 GRIBDEC: Done % ./gribdec.k ~/gribdata/2003061300_d1_f06.grb 6000 NUM=1 Year of Century = 3 Month of Year = 6 Day of Month = 13 Hour of Day = 6 <--- 6 Minute of Hour = 0 ConvertForecast:: Forecast Time Unit = 1 ConvertForecast:: P1 - Period of Time = 0 <--- 0 ConvertForecast:: P2 - Period of Time = 0 ConvertForecast:: Time Range Indicator = 0 Input GRIB file: /home/mcidas/gribdata/2003061300_d1_f06.grb Output GRID file: GRID6004 GRIB messages:: Found: 2 Decoded: 1 Written: 1 GRIBDEC: Done ... I interpret this to mean that the grib message PDS section values for Hour of Day (PDS word 16) and P1 - Period of Time (PDS word 19) have somehow been interchanged: - the Hour of Day value should stay at 0 (zero) for all forecasts for the model run while - the forecast time (which is a function of the Forecast Time Unit and the P Periods of Time and Time Range Indicator) should increase with each forecast output Cheers, Tom >From address@hidden Fri Jun 13 13:17:18 2003 Tom, Thank you for this! Yes, you are correctly, as far as I understand it, interpreting the file names on the AMPS web site correctly - Kevin Manning would know best. In quickly reviewing your findings, it appears that there is indeed a problem with the GRIB coding that needs to be fixed...is that right? If so, then Kevin - can you fix this?? Once you do it will make sure of the GRIB files much, much more useful, as for right now we loose the run time of the model data. Thanks so much everyone!! Matthew >From address@hidden Fri Jun 13 13:22:39 2003 Just had a chance to check this myself (workshop all week). It looks like Tom's diagnosis is right. It shouldn't take much to fix this; maybe even by the next 00Z job. Thanks, all, for your patience. --Kevin >From address@hidden Fri Jun 13 13:32:32 2003 Thank you Kevin!! (Now I just need to dig up the disk space to host all of this data routinely!!) Matthew
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.