Model run

Model run is the term used for one complete model calculation of atmospheric conditions for a determined forecast range (days). The run is also called model update .

Modelling process

model run consists of :
  1. Initialisation: process of entering observation data into a model, to generate "initial conditions" (initialisation time) at which the model begins the calculation of conditions.
  2. Assimilation: collection, quality control and normalisation of all observation data, which describe the initial state of the atmosphere. The result is an sssembly of data in a format which permits the start of computation.
  3. Computation: Calculation of future atmospheric rates of change  in time increments called a time step. Time steps are typically 4 seconds.
  4. Data extraction: During computation, data are extracted in regular forecast intervals. meteoblue uses 1 hour intervals for NMM models. 
  5. Data storage: After computation, the model data are written into accessible formats. 
  6. Data postprocessing: For certain applications  (e.g. Calculation of Opens internal link in current windowpictograms, Station forecasts, Opens internal link in current windowEnergy forecasts), the data are further submitted to special processing routines.

The model run is finished with completion of the postprocessing: the completion marks the actualisation time. This is when the data are available for various products .
 

Frequency of model runs

For the NMM models , meteoblue generally uses 2 model runs per day, 
The runs are based on the assimilations for 00:00 UTC and 12:00 UTC. Initialisation generally takes place 2 hours after assimilation. Actualisation are made between 6 and 8 hours after assimilation.
The time of initialisation of the model run can be distinguished from the image or data set. Generally, forecast range displayed is:
  • 00:00 UTC initialisation: from 00:00 UTC onwards (day 1 has 24 hours of data).
  • 12:00 UTC initialisation: from 12:00 UTC onwards (day 1 has 12 hours of data).

The actualisation times are displayed in the following way:

  • Diagrams (e.g. meteogram): in the title or subtitle (in UTC).
  • Data FTP: the actualisation times are the time stamps of the transfer file.
  • Data per API: the data actualisation times are not displayed individually, to preserve file formats. They can be checked using a corresponding diagram.

The current actualisation time can be checked live on the meteoblue website.

Quality of model runs

Other sites update 4 to 8 times per day: Why does meteoblue only calculate 2 model runs per day? With meteoblue NMM technology, the results of 2 daily runs alreay produce very high quality.
Here are some reasons for that:

  1. Assimliation quality: good global assimilation data can be obtained 2 times per day. The interim updates (06:00 and 18:00 UTC) are less complete. Therefore, the forecast quality of the model runs based on 06:00 and 18:00 UTC assimilation is lower than for the preceeding assimilation.
  2. Local modelling: meteoblue models are of high resolution and produce more localised data than the conventional models, which require corrections through weather station measurements. meteoblue models do not need statistical corrections using weather station data. 
  3. Limited ability of statistics: Short-term updates (using weather stations or satellite measurements) only improve the forecast for the next 1-3 hours. Statistically, a 6-hour forecast produced with a weather station measurement (e.g. a forecast produced at 10:00 UTC for 16:00 of the same day, based on weather station data from 09:00 UTC) is inferior to a model forecast for 15:00 based on 00:00 assimilation.

What matters is not how often you update, but how well!
 

Maximizing model data quality

To offer constant best quality forecast, meteoblue uses a combination of strategies:
  1. Cover large areas with high spatial resolution: we use the computation power to calculate more model domains, thereby improving the data quality in much larger areas.
  2. Nowcasting for special parameters: we use special techniques to produce short-term forecasts such as rainNOW:
  3. User reporting: we offer the me-T☼-u user messaging service, which enables users from the entire world to report actual conditions, permitting a continuous comparison to reality.
  4. Specialised forecasts: for applications which are very dependent on precise local weather information (like wind power forecasting and building management), meteoblue makes specialised adaptations of the forecast using local weather measurements.
  5. Comparison to measurements: with the meteogram CLIMA, we show how the predicted weather compares to previous years, giving users a measure of probability.
  6. Quality control: by continued comparison to measurements, we control our forecast quality and improve it continuously.

Thereby, we offer our users have different options to receive the best forecast for their specific requirements. "What our users say" tells you some of the results.

Model data generation (for programmers)

A schema of the meteoblue model forecast update Process is shown in the graph attached.

Timing of data availability depends on the model domain and the process steps involved in data generation (e.g. postprocessing, MOS) and data transmission (e.g. API, FTPmail or others ).


NMMNumerical Mesoscale Model.
pointPRO = all professional local services (PORT ; PULL; APIPLUS);
MOS  = Model Output Statistics.