You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 1, 2022. It is now read-only.
Complex mixed interval variables are a pain. This issue shows up in GRIB. For an example, check out the variable Total_precipitation_surface_Mixed_intervals_Accumulation as found in the GFS Global 0.25 degree GRIB collection.
The valid forecast time associated with this variable has values of:
3, 6, 9, 12... hours since the model runtime.
Looks like three hour accumulations of precipitation, yes? Well, no, that would be too easy. This is a mixed interval accumulation, so one must look at the time bounds associated with each valid forecast time. What do those bounds look like?
valid forecast time
interval start
interval end
3
0
3
6
0
6
9
6
9
12
6
12
Which translates into the following:
Total accumulated precipitation over the past three hours valid for a forecast time three hours into the model run.
Total accumulated precipitation over the past six hours valid for a forecast time six hours into the model run.
Total accumulated precipitation over the past three hours valid for a forecast time nine hours into the model run.
Total accumulated precipitation over the past six hours valid for a forecast time twelve hours into the model run.
Wait, what? See the issue? [hint: where is total accumulated precipitation over the past three hours valid for a forecast time six hours into the model run?]
In order to get the missing 3 hour accumulations, one must do some subtraction - no big deal, and GEMPAK does this behind the scenes. In the example above, we would need to do:
T_{v:6, I:3} = T_{v:6, I:6} - T_{v:3, I:3}
where v is the valid forecast time, and I defines the interval width in time.
The proposal is to create a client side method to reduce these "complex mixed intervals" into something that is more simple (i.e. all three hour intervals instead of a mixture of three and six hour intervals).
The text was updated successfully, but these errors were encountered:
Complex mixed interval variables are a pain. This issue shows up in GRIB. For an example, check out the variable
Total_precipitation_surface_Mixed_intervals_Accumulation
as found in the GFS Global 0.25 degree GRIB collection.The valid forecast time associated with this variable has values of:
Looks like three hour accumulations of precipitation, yes? Well, no, that would be too easy. This is a mixed interval accumulation, so one must look at the time bounds associated with each valid forecast time. What do those bounds look like?
Which translates into the following:
Wait, what? See the issue? [hint: where is total accumulated precipitation over the past three hours valid for a forecast time six hours into the model run?]
In order to get the missing 3 hour accumulations, one must do some subtraction - no big deal, and GEMPAK does this behind the scenes. In the example above, we would need to do:
where
v
is the valid forecast time, andI
defines the interval width in time.The proposal is to create a client side method to reduce these "complex mixed intervals" into something that is more simple (i.e. all three hour intervals instead of a mixture of three and six hour intervals).
The text was updated successfully, but these errors were encountered: