[gradsusr] Reading timesteps in Arpège grib2 file

Chorley Weather weatherstu at chorleyweather.com
Mon Jan 18 04:39:37 EST 2016


 

Hi Guys, 

How would this work around apply to windows users who use perl!!!!
Normally a ctl file would be produced like such: 

@ECHO Please wait, concetenating grb files...
cat *.grb > gfs_grib.grib2
@ECHO Please wait, creating ctl file...
perl g2ctl.pl -verf gfs_grib.grib2 > gfs_grib.ctl
@ECHO Please wait, creating idx file...
gribmap -i gfs_grib.ctl -e 

regards, 

Stuart 

On 17-12-2015 22:17, Brian Gaze wrote: 

> Wesley, 
> 
> Many thanks for the explanation and solution using alt_g2ctl and alt_gmp. 
> 
> Brian 
> 
> On 17 December 2015 at 13:14 Wesley Ebisuzaki - NOAA Federal <wesley.ebisuzaki at noaa.gov> wrote: 
> 
> Brian, 
> I am being pedantic because I hope that the ARPEGE and AROME people will get word and fix their grib2 files. 
> In order for GrADS to plot the ARPEGE file, GrADS needs to know the time of the fields. For Product Definition Template (PDT) 4.8 which is 
> used to describe averages and accumulations, there are 3 different times. 
> Reference time: start of the forecast 
> 
> Section 1, octets 13-19 
> 
> Start of the forecast time interval: 
> reference time + forecast time (Section 3, octets 18-22) 
> 
> End of the forecast time interval: 
> Section 3, octets 35-41 
> 
> For your ARPEGE file, the only unique time should be the end of the forecast 
> time interval. However when you examine the ARPEGE file. 
> 
> ebis at linux-landing:~/Downloads$ wgrib2 ARPEGE_0.1_SP1_37H48H_201512150000.grib2 -s -start_ft -end_ft -match PRATE 
> 133:32079786:d=2015121500:TPRATE:surface:0-37 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 134:32391856:d=2015121500:TPRATE:surface:0-38 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 135:32706662:d=2015121500:TPRATE:surface:0-39 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 136:33024062:d=2015121500:TPRATE:surface:0-40 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 137:33344053:d=2015121500:TPRATE:surface:0-41 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 138:33666613:d=2015121500:TPRATE:surface:0-42 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 139:33991684:d=2015121500:TPRATE:surface:0-43 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 140:34319034:d=2015121500:TPRATE:surface:0-44 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 141:34648323:d=2015121500:TPRATE:surface:0-45 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 142:34979540:d=2015121500:TPRATE:surface:0-46 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 143:35312524:d=2015121500:TPRATE:surface:0-47 hour acc fcst::start_ft=2015121500:end_ft=2015121600 
> 144:35647622:d=2015121500:TPRATE:surface:0-2 day acc fcst::start_ft=2015121500:end_ft=2015121700 
> 
> You see that the TPRATE (totat precipitation rate) has the end of 
> the forecast time interval of 2015121600 which is wrong. This ARPEGE file 
> needs to be fixed. A few weeks ago, someone sent me a AROME 
> forecast file which had the same problem. 
> 
> So g2ctl and gribmap will not work until the grib file is fixed. 
> 
> You can display the fields using 
> 
> alt_g2ctl -0t ARPEGE_0.1_SP1_37H48H_201512150000.grib2 >a.ctl 
> alt_gmp -i a.ctl 
> 
> This solution gives each field a unique name and doesn't use the 
> end of the forecast time. 
> 
> Maybe someone will inform the ARPEGE and AROME people and they 
> will fix their files. 
> 
> Wesley 
> 
> On Thu, Dec 17, 2015 at 6:13 AM, Brian Gaze < brian.gaze at ntlworld.com> wrote: 
> 
> Wesley, 
> 
> You can ftp down the grib file here using anonymous: 
> 
> 137.135.248.188 
> 
> ARPEGE_0.1_SP1_37H48H_201512150000.grib2 
> 
> PS: It's about 40 meg and I tested the ftp download successfully from a command line rather than gui client 
> 
> Cheers 
> 
> Brian 
> 
> On 16 December 2015 at 15:03 Wesley Ebisuzaki - NOAA Federal < wesley.ebisuzaki at noaa.gov> wrote: 
> 
> Brian, 
> 
> It would be much easier if you made your grib file available 
> by FTP. If the file is huge or is a proprietary forecast, you can 
> zero out the data by 
> 
> wgrib2 file.grib -rpn 0 -grib_out file00.grb 
> 
> Wesley 
> 
> On Tue, Dec 15, 2015 at 4:32 PM, Brian Gaze < brian.gaze at ntlworld.com> wrote: 
> 
> Hi, 
> 
> I'm working with Arpège grib2 files. These should I think each contain up to 13 hourly forecast timesteps. If I run... 
> 
> g2ctl.pl [1] -verf -b file.grib2 > file.ctl
> gribmap -i file.ctl 
> 
> ...I'm able to open the .ctl file in GrADS but it only has 2 timesteps. T1 seems to be the time the model was initialized and T2 the time of the first forecast step. 
> 
> If I try: 
> 
> g2ctl.pl [1] -b -ts1hr file.grib2 > file.ctl
> gribmap -i file.ctl 
> 
> It opens ok in GrADS and the correct number of timesteps are present but they begin from the model initialization hour rather than incrementing from the time of the first forecast step. For example: 
> 
> Model initialization: 0z 15/12
> Forecast time range contained in the file is +37 hours to +48 hours after initialization 
> 
> t2 = 1z 15/12
> t3 = 2z 15/12
> .. etc
> 
> As a consequence, when I try to plot a variable the grid is undefined. 
> 
> What should I think be present is:
> t2 = 13z 16/12
> t3 = 14z 16/12
> ..etc 
> 
> Any suggestions / ideas on what I'm doing wrong? 
> 
> Thanks 
> 
> BWG 
> _______________________________________________ 
> gradsusr mailing list 
> gradsusr at gradsusr.org 
> http://gradsusr.org/mailman/listinfo/gradsusr [2]

_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr [2]

-- 

Stuart Markham 

 

Links:
------
[1] http://g2ctl.pl
[2] http://gradsusr.org/mailman/listinfo/gradsusr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20160118/148c334d/attachment.html 


More information about the gradsusr mailing list