[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030612: AMPS grib data (cont.)
- Subject: 20030612: AMPS grib data (cont.)
- Date: Fri, 13 Jun 2003 13:09:30 -0600
>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[12] 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