Global, regional and national Numerical Weather Prediction Use Case

User Story

There are only about 20 institutions that routinely forecast the weather 24/7 for the whole globe. However there are at least 70 National Hydro-Meteorological Services running higher resolution, limited area, NWP models, and several private sector companies too. To maintain sufficient accuracy, these limited area models require specified boundary conditions, which must come from one of the global models.

Transmitting a complete set of grid point values for the limited area is very demanding, so that a 4D 'shell' or 'halo' of grid points, several grid points wide, surrounding the limited area, are transmitted. Halo values are needed for the full vertical extent of the the limited area model, so the 2D halo becomes 3D. The halo of boundary values are also needed for the full duration of the forecast. They could be every hour for 3 days, for example, rather than every time step. Thus the 3D halo becomes 4D.

Normal practice is to tailor a specific 4D 'halo' for each limited area model. As the number of higher resolution, limited area, models increase, it may become more effective to build each 4D halo from a single set of data cubes from one global model.

Also, if different global models produced compatible data cube sets, the limited area models could have increased resilience by having potential multiple sources for their boundary conditions.

Actors

1. Global forecast server supplying data tiles bounding the Volume and for the Period Of Interest.
2. One client, of several, receiving data tiles local to clients' Volume boundary and Period Of Interest.
3. Intermediate web caches to allow other clients to receive the same tiles if of interest.

Preconditions

The server and client have negotiated a tile service for an Volume and Period Of Interest.

Main Success Scenario

As the client local forecast model evolves in time, the client's local copies of data tiles are replaced and out-of-date data tiles are deleted. The data tiles received allow the client to forecast the local weather with appropriate boundary conditions.

Postconditions

The recently used/requested tiles remain in the web cache, and are re-labelled ('time-shifted') as backup for the next set of tiles. I.e. After 24 hours, the 2 day forecast is re-labelled as a 1 day forecast and used if the latest 1 day forecast not received.

Alternative Paths

1. Server/Client communication fails for a significant duration, so instead of the latest set of boundary Volume tiles, the previous used/requested tiles remaining in the web cache, are re-labelled ('time-shifted') and used as backup for the next set of tiles. I.e. After 24 hours, the 2 day forecast is re-labelled as a 1 day forecast and used if the latest 1 day forecast not received. This requires the server to forecast for longer than the client.

Requirements Issues/Discussion

1. Each tile could have a time extent with several data times, or each tile could have data only for one instant and separate tiles must be requested to cover a time period.
2. Each tile could have a vertical extent with several data altitudes/levels, or each tile could have data only for one level and separate tiles must be requested to cover a vertical extent.
3. Each tile could contain several different parameters of interest, or each tile could have data only for one parameter and separate tiles must be requested to cover that dimensional extent. E.g. Vector or tensor valued parameters, such as wind components or current speed and direction should probably be in the same tile.
4. There could be a set of 'volume tiles' and a separate set of 'surface tiles', as the distribution of parameters in the volume of the atmosphere and oceans and their surface are significatnly different.
5. It is envisaged that tiling is primarily horizontal (x,y) in extent, with z and t coordinates 'added'. It is possible that the primary tiling could be in, say (z,t) space.

-- Main.clittle - 16 Jun 2015