-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better NWP time selection #253
Comments
can i get more info on this issue to work upon |
Hi @vikasgrewal16, sorry for the delay. I have added a little bit to the description. We have some sample GFS forecasts on huggingface, which might be useful to understand the issue. A few successive forecasts can be found here. I'm describe the issue a little more below, but I first want to point out that this might be a little complex as a first issue, but it is at least somewhat self contained to a couple of functions. So just a heads up The basic issue comes when we want to take a time slice from the forecasts. We often want to slice a from an hour or two behind until several hours ahead. The hour or two behind now (call now t0) gives us some context to what is happening at t0. Generally, an NWP is initialised at some time and run into the future and they save out hourly forecasts. Most NWPs do this for the very first step (i.e. hour zero) but GFS does not. Previously we had assumed that all NWPs would have a zero hour output. So say there was a GFS forecast that was initialised at time 12:00 and now it is 13:00. Say we also want to slice from 2 hours behind t0 until 8 hours ahead. Then we would need to select 11:00 and 12:00 from the GFS initialisation which came before the initialisation at 12:00. We would also select the 13:00-21:00 from the 12:00 initialisation. As it stands the code it set up to assume that the 12:00 intialisation contains a forecast for 12:00. All the other NWP providers do this but GFS does not. So this issue is to address this difference and allow the time slicing to depend on the steps available at any initialisation. |
When loading the GFS data we interpolate the step 0 forecast because it doesn't have this step (unlike the other NWP providers). See here.
Instead we should modify around here in the NWP time slicing to be able to slice this valid time from the previous init-time.
We may also need to modify the NWP contiguous time function to allow for the lack of the zeroth step
Also, at least some of the GFS variables are cumulative, so we might need to take a diff before slicing. However taking
ds.diff()
is not done lazily, so this would need to be done with some care to avoid loading the whole dataset into memory but getting the time steps we requestThe text was updated successfully, but these errors were encountered: