[gradsusr] Multiple accumulation periods

Wed Mar 14 10:50:39 EDT 2018

Hi, Scott — 
There are lots of slots for grib2 codes in the variable declaration (in the levs, additional codes, and units fields), but none of them is used for specifying any time metadata. For time stamping, you have a two choices: reference time (the forecast initialization) or valid time (initialization plus forecast interval). If the parameter in question is an average or an accumulation over a period of time, then you have two options for the valid time — the beginning or the end of the average/accumulation period.  These choices are specified using different switches with gribmap. The default is to match at the valid time using end of the average/accumulation period. Use the “-0” option to match at initialization time, and use “-b” to match at the beginning of the average/accumulation period. 

The only way to distinguish between your three parameters (prob>2, prob>4, and prob>6) at the different accumulation periods is to use the “-b” option with gribmap and have a TDEF that has 5 time steps (V-24h, V-18h, V-12h, V-6h, and V), where V is the valid time at fh246. Actually, you could have a TDEF size 4 (skipping the final valid time V), but I am guessing there are other records in the file that are not accumulations or averages that would match at time V. 

This strategy would allow you to keep all the records for fh246 in one file, but becasuse the file has a range of ‘valid’ times, you would not be able to template all the different forecast hours together into one long time series. So you have a choice: break up the data files to tease out the different accumulation periods, or create separate descriptor files for each forecast interval. 

To answer the question of ‘which record am I looking at’ when there are multiple records in a file that have identical parameter codes and will match at the same valid time… As gribmap scans the data file, it writes the file offset position (in bytes) into the index file for each record that matches the metadata for a particular variable/Z/T/E. If gribmap finds a duplicate, it doesn’t notice or care, it just overwrites the current file offset into the proper slot in the index file. The duplicate record that occurs last in the file is the one whose position is stored. 

I hope this helps to clarify the situation. 
—Jennifer

> On Mar 13, 2018, at 4:12 PM, RENTSCHLER, SCOTT A GS-12 USAF ACC 16 WS/WXNM <scott.rentschler.1 at us.af.mil> wrote:
> 
> All - 
> I'm generating some post-processed information based off an ensemble.  So for example, I might be generating the following parameters:
> ASNOW Total Snowfall [prob]:surface:240-246 hour acc fcst:prob >2:probability forecast
> ASNOW Total Snowfall [prob]:surface:240-246 hour acc fcst:prob >4:probability forecast
> ASNOW Total Snowfall [prob]:surface:234-246 hour acc fcst:prob >4:probability forecast
> ASNOW Total Snowfall [prob]:surface:234-246 hour acc fcst:prob >6:probability forecast
> ASNOW Total Snowfall [prob]:surface:222-246 hour acc fcst:prob >2:probability forecast
> ASNOW Total Snowfall [prob]:surface:222-246 hour acc fcst:prob >6:probability forecast
> …and I’m writing these fields in GriB2 format.    In this example, I’m generating the data off of the GFS ensemble, writing out the information every 6 hours, with data valid at that forecast hour.   So the above records appear in the 246 hour forecast file.
>  
> Note that we have a couple of fields then that, when using g2ctl, or even alt_g2ctl, would have identical variable names as they only differ in the accumulation period –
> ASNOW Total Snowfall [prob]:surface:240-246 hour acc fcst:prob >2:probability forecast
> ASNOW Total Snowfall [prob]:surface:222-246 hour acc fcst:prob >2:probability forecast
>  
> ASNOW Total Snowfall [prob]:surface:240-246 hour acc fcst:prob >4:probability forecast
> ASNOW Total Snowfall [prob]:surface:234-246 hour acc fcst:prob >4:probability forecast
>  
> ASNOW Total Snowfall [prob]:surface:234-246 hour acc fcst:prob >6:probability forecast
> ASNOW Total Snowfall [prob]:surface:222-246 hour acc fcst:prob >6:probability forecast
>  
> The g2ctl utility outputs the following entries into the control file:
> ASNOW2e3GTsfc  0,1,0 a1,2   0,1,29,1 ** surface prob >2 Total Snowfall [prob]
> ASNOW4e3GTsfc  0,1,0 a1,4   0,1,29,1 ** surface prob >4 Total Snowfall [prob]
> ASNOW6e3GTsfc  0,1,0 a1,6   0,1,29,1 ** surface prob >6 Total Snowfall [prob]
>  
> The alt_gt2ctl:
> ASNOWdprob_>2dprobability_forecastsfc 0 0 "ASNOW.prob_>2.probability_forecast:surface" * ASNOW.prob_>2.probability_forecast:surface
> ASNOWdprob_>4dprobability_forecastsfc 0 0 "ASNOW.prob_>4.probability_forecast:surface" * ASNOW.prob_>4.probability_forecast:surface
> ASNOWdprob_>6dprobability_forecastsfc 0 0 "ASNOW.prob_>6.probability_forecast:surface" * ASNOW.prob_>6.probability_forecast:surface
>  
> …and alt_g2ctl using the “–short” flag:
> v1 0 0 "ASNOW.prob_>2.probability_forecast:surface"
> v2 0 0 "ASNOW.prob_>4.probability_forecast:surface"
> v3 0 0 "ASNOW.prob_>6.probability_forecast:surface"
>  
> My problem is that I’m unsure how to reference the different accumulation periods for the given parameters.  If I were to create a template for a 246 hour forecast period, and within the GrADS command line interface, input “set t=42”, and try to display one of the above parameters, how do I know which one I’m displaying and how does one switch to a different accumulation period?  I’m hoping to avoid creating new files containing subsets of the above data, but at the moment I’m not sure how to work around it.  Is there a way to give each accumulation period a unique ID or an appropriate mechanism for identifying differing accumulation periods for a given parameter?
>  
> Thanks!
> Scott
>  
>  
> //Signed//
> Scott Rentschler, Meteorologist
> Fine Scale / Ensemble Models Team
> 557th Weather Wing, 16WS/WXN
> DS: 271-3331 Comm: (402) 294-3331
>  
>  
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://secure-web.cisco.com/1hHIpPnNWTSDW4NuwoWseEegvopJbNZ5e9_FaBAaBXy6qwZbPAXTABgVmizVjayrdh7r0KguEzyyiSHFq-dKA-T1LokHl0rd2vc_av4gvqjKl6AdS03YDXGrfKIXPvsmEKsMNIljq5VlraDkfWv80QD1bfB6zsabcDa8vjqVfDA95KI3s_aFywGLkXwDQmxqDx82bBmJAb0mfSgJyhX2a6EBFhuSCaz4bXomZhRGm6VDifI3jfUlYLjCfmtkqjDN39TkSG_rGSzgwvGpsDetp57mgEbCbLuLFFKw9VqFwBw00UtMzdf1Yj4A8FZTZlIjOoMt4w-ZSiU0O9ncGJHz9QDvSXbDMlVf4PA4CeSBnEIubuH26YqGH6PdGfwFtdoZ7OQ8xq6SFvC4s3mugWw_YlHxE_R5YR6R3AXmkpKg8nOLc9XQ5M9_nk6GeYyovlAJX/http%3A%2F%2Fgradsusr.org%2Fmailman%2Flistinfo%2Fgradsusr

--
Jennifer Miletta Adams
Center for Ocean-Land-Atmosphere Studies (COLA)
George Mason University