[Discussion] Is this how MSFS combines MB forecast and METAR?

Hi all,

I am very curious how live weather is generated in MSFS and just spent some time over the weekend trying to illustrate this process based on the information provided from last Q&A session. Could someone chime in and let me know if my understanding is correct?

BTW, is there a sub-forum for technical related discussion? (not SDK forum but more like discussion about algorithm, forecast models, ML/AI models, backend system, etc. behind MSFS?)

Some context on chart settings

  • Y axis - some arbitrary altitude level used to differentiate forecast values
  • X axis - some arbitrary location value used to differentiate positions of airports of stations
  1. MeteoBlue Forecast - some quick comments here

    • Continuous through either vertical or horizontal space
    • Continuous through time
    • The whole forecast may be based on information available a few hours ago and is updated twice a day?
  2. METAR Stations or Airports

    • Example: 3 stations here
    • Real weather reading at a given location - discontinuous in horizontal space but may not be discontinuous in vertical space at the given location
    • Snapshotted - discontinuous in time
    • Updated every 30min to 1hour?
  3. Combined - MSFS Live Weather

    • ATIS at the airport - METAR reading
    • Other locations - blend between METAR and MB forecast
    • The weight is likely biased towards MB forecast in most cases

Edit: Need to sleep now. Will check tomorrow …

2 Likes

I don’t know the exact details of MeteoBlue’s forecast model, but almost forecast models encode their data in a standardized format known as GRIB.

A worldwide model will have a standard latitude/longitude grid with a specific spacing between grid points. The NEMS model that MeteoBlue is using for MSFS has a 30 kilometer spacing between grid points. Some high-resolution regional models may have a much closer grid spacing - sometimes as little as 2 kilometers between adjacent points. That would be impractical for a model designed for worldwide coverage, as the resulting data file would be enormous.

For each grid point, there will be standardized vertical levels. Typically 2 and 10 meters above the ground, and then standard pressure levels which (indirectly) correspond to altitudes. A typical set of pressure levels might be 1000, 850, 700, 500, 300, 250 and 150 millibars, which correspond to altitudes between approximately 1000 feet and 39,000 feet MSL. Some models may have many more discrete pressure levels than those.

For each vertical level, there would be data such as temperature, dew point, height of the pressure surface above sea level, (which varies from day to day and hour to hour), wind speed and direction, relative humidity etc.

Most models will contain other data types more of use to meterorologists, such as absolute and relative vorticity, vertical motion, potential temperature, equivalent potential temperature etc. These latter data types are not directly used by pilots, but they can predict whether clouds or precipitation will exist at a specific location or altitude, and what type of clouds or precipitation might be present.

Based on the information contained in MeteoBlue’s partnership video, they apparently subdivide the model grid into smaller sub units both horizontally and vertically, and interpolate values in both directions. This would NOT be the same as having a model with a higher number of grid points to start with. What MeteoBlue is probably doing is using an averaging algorithm to create values at intervals between their standard grid points horizontally, and between discrete pressure levels vertically.

As far as how the model data is actually translated into the in-sim weather is something I could only speculate on, and something which only MB and Asobo would know for sure.

The forecast model is run twice each day, at 0000Z and 1200Z, and each model run will contain values for each grid point for each discrete hour from the model start time, out to 24 hours.

The model data is strictly a prediction of what the weather “might” be.

IF the MeteoBlue weather data is imported into Microsoft’s Azure servers in a timely fashion, then for any given location and time, you should get the predicted weather for that specific location and time. Many of us have reason to think that process does not always work correctly.

METAR data is not a prediction. It is based on real-time observations made either by human observers or by automated weather equipment like AWOS. METARS are only taken at airports, and not all airports (especially smaller ones) report weather.

A METAR report will normally include time of the observation, wind speed and direction, cloud layers (height above ground and coverage), temperature and dew point, visibility and barometric pressure (corrected to sea level), and any precipitation that may be occurring.

METARS are normally taken once per hour, though new METARS may be generated more often if conditions are rapidly changing. The kinds of changes that would be cause to generate an updated METAR would include a significant shift in wind direction or speed, rapid temperature change, significant change in visibility, the beginning or ending of precipitation, thunderstorms etc.

Based on the recent Q&A, Asobo confirmed that they are using METAR data for airport surface weather. They did directly state that they are using the METAR wind speed and direction, but did not specifically mention whether they are also using METAR temperature or pressure. Also, they did not specify how often the airport METAR data is updated. If the actual airport weather is relatively unchanged, then there would only be new METAR data available once per hour at best.

They did not specify how the surface data is blended with the MB model. I would assume there would be some kind of smoothing algorithm in play to gradually transition the actual surface winds to the predicted winds above the surface. If there is a large disparity between actual and predicted winds, the transition might be rather abrupt.

I would bet anything that the clouds and precipitation (if any) come exclusively from the MeteoBlue model, and not from METAR cloud reports. It would be much too difficult to blend the two if there was a significant difference between the prediction and the actual observation.

Everything I have said here is speculation - I have no inside information on how Live Weather is actually implemented in the game.

10 Likes

I think your description checks out, and is what the simulator weather should be doing in theory. I don’t think they’ve fully implemented this in practice, however.

Trying to make a graphic plot like this, perhaps make each “dot” on the MB model plot a 30 km wide rectangle instead? We’re short on specifics on the vertical layers, but I believe numbers like 20 layers or 64 layers were thrown out during the weather feature discovery video, depending on what kind of weather variable they’re working with.

Just guesses here, but the simplest way to blend in the METAR data would be to make the stations 1D points that linearly interpolate to the Meteoblue model grid cell boundaries. Maybe they instead have a radius with a transitional zone? But on your graph the smoothing might be much larger horizontally, and is probably much shorter vertically. It probably makes sense to much more quickly switch over to the MB model as you go vertical rather than blending in surface obs with data aloft.

A quirk on the update cycle: I think most folks would assume the METAR data is more accurate, but it’s possible that blending in METAR data results in older/out of date weather. The METAR observations might be an hour old already, while the Meteoblue model has a forecast that is 0 hours old (but based on data and a model run that is a few hours old). If the forecast is correct, the model will be more accurate than the METAR.

I’ve seen this happen with frontal passages in the Midwest here, which can cause a 180 degree shift in the winds. If the model has the frontal passage timing down, then the METAR could lapse for an hour with the wrong winds while the forecast made hours ago shows the correct winds. Referencing your graph, that would certainly cause a “red island” in a “blue sea” type situation where the “red” METAR weather is quite a bit different than the “blue” model weather.

2 Likes

I saw this situation yesterday in Charlotte (KCLT). I landed at about 17:30 local time.

Actual METAR had southwesterly winds, temp 18C and pressure 29.97

Live Weather was generating northwesterly winds, temperature of 2C and pressure of 30.26.

Reading the NWS Forecaster’s Discussion for CLT, they were expecting a frontal passage later yesterday evening, with a wind shift, falling temps and rising heights.

Indeed, what Live Weather was providing at 2230Z yesterday, is a very close match to the actual KCLT METAR at 0925Z today - almost 11 hours later.

My conclusion: no part of the KCLT METAR was being used by Live Weather yesterday. The winds were southwesterly almost all day, and did not shift to the northwest until several hours after my landing.

If all the KCLT surface weather was from MB, then either the model was way off in its prediction of the frontal passage - placing it much farther east than its actual position at the time, or (more likely), the Live Weather system injected the wrong forecast hour data from the model - giving the prediction for early this morning, rather than the prediction for the actual time in-game.

In the past, a common problem has appeared to be that the forecast model has been delayed - seemingly giving clouds, temperatures and pressures from many hours prior to the in-game time. Recently, a couple of other users have reported that the opposite is happening now - where Live Weather sometimes appears to be setting the weather that is likely to occur several hours later than the in-game time. That certainly appeared to be what was happening yesterday on my flight to KCLT.

i would assume that the discrete forecast hours in the MB product are stored by UTC date and time. I would further assume that MSFS gets its notion of what the current UTC time is from the computer’s internal clock. The offset (plus or minus) between UTC and local time will depend on the time zone settings in the Windows control panel. Any disparity here could lead to problems with getting the right MeteoBlue forecast hour.

Most computers are set to display local time. If the computer is physically located in the Eastern Time Zone, but the regional settings are set for the Pacific Time Zone, the local time would appear correct (once set initially), but the UTC time in Windows would be 3 hours off. Since the majority of computer users never deal with UTC, they would have no way of knowing if their computer has the right UTC offset.

Alternatively, (and preferably) MSFS might get its notion of current UTC time by independently querying an NTP time server. That would be preferable because it would eliminate any issues caused by the computer’s own internal clock being set incorrectly - especially any disparities between the actual UTC date/time and the computers internal UTC date/time.

Windows itself can be configured to sync its date/time by querying an NTP server at regular intervals, but not all users have that option set to “on”, and even if the NTP sync is enabled, it won’t give the correct UTC time if the computer’s time zone setting is incorrect.

I’m going to do an experiment. I am going to deliberately set the wrong local time zone in Windows, fire up MSFS, and see what Zulu time comes up in-game when I select Live Weather. If the Zulu time is “off” after doing this, that would indicate that MSFS gets its UTC time from the computer’s own internal clock. If it remains unchanged, that would indicate that the UTC time in MSFS is being independently synced to an external time server. I’ll report back later with my findings.

3 Likes

Thanks for the reply. I agree that the chart would be more accurate if I made the data point 30KM apart.
In another thread there’s discussion about how live weather was implemented in MSFS and I was speculating that depending on how cached METAR or MB forecast data was evicted for the new update, there’s another layer of uncertainty

Thanks a lot for your detailed reply.

I always appreciated your response and took time to digest.

Right now, I am thinking if there’s a way to capture ATIS information & external METAR (and potentially MB forecast) simultaneously in a systematic way to help understand the challenge here

So, I tried my experiment. I live in the US Eastern time zone which is currently UTC-5. My Windows time setting has the correct time zone selected. (EST)

When I Ioaded MSFS, and selected my home airport in the Eastern time zone (KELM) the Live Weather dialog showed the correct local time (1300), and correct UTC time (1800). This gave wind 317 at 37, temperature +3 C and pressure 29.98, with partly cloudy conditions. This is quite close to actual conditions.

Current METAR at KELM is wind 330 at 28, temp +3 and pressure 29.95. The Live Weather wind was higher, temperature was exactly the same, and pressure was 0.03 higher.

I exited the sim, and went to the Windows time settings. I changed my local time zone to Alaska, which is UTC -9. This caused my local time on the task bar to change to 1700. I set it back to the correct 1300. But now, the computer “thinks” it is in Alaska, and that the local time is 9 hours behind UTC.

I started the sim, and reloaded at KELM with Live Weather active. Now the time dialog in Live Weather shows a UTC time of 2200 which is indeed 9 hours beyond Alaska standard time. (And 4 hours later than actual UTC).

Now the sim “thinks” the local time at KELM is 1700, which would be correct for 2200Z. The live weather wind was now 297 at 36, temperature was -1C and pressure was 29.89, and the sky was clear. This is quite close to the MOS forecast for KELM for 4 hours from now from my local NWS forecast office.

This tells me several things.

The simulator calculates the current UTC time from Window’s own internal clock. It does this by applying the UTC offset for the current Windows time zone to the Windows local time. If either the local time or local time zone are set incorrectly, the UTC time in the sim will be wrong.

The particular Live Weather conditions you get absolutely do depend on the sim’s “opinion” of what the current UTC time is. When I deliberately forced to sim UTC to be 4 hours later than actual UTC by manipulating the Windows time zone setting, I got a different set of temperatures, pressures, sky conditions and winds than when the sim UTC was correct.

I am not convinced that the sim wind is actually coming from current METAR, despite what Asobo stated in the Q&A - at least not for my local airport. Even with the UTC correctly set, the wind direction was 10 degrees different, and speed 10 knots higher, than current METAR. It was reasonably close - but not exact.

Obviously real time METAR cannot be used when the sim UTC is deliberately set 4 hours beyond current UTC, since that time does not yet “exist” fir real works METAR observations.

Whatever current problems might exist with Live Weather serving up incorrect data due to problems at Azure’s end, it is absolutely essential that the sim computer’s internal clock be accurately set to the local time where the computer is physically located, and most importantly that the Windows time zone setting be correct for the computer’s physical location. If either local time and/or time zone settings in Windows are wrong, the sim will have the wrong internal UTC time, and will not give the correct MeteoBlue forecast for the aircraft’s current location and time.

1 Like