Resolved Sudden transition out of thunderstorms

mmcmah

Active member
Climbing out of thunderstorms into into blue skies, but with sudden transition from storms to lower cloud cover at about 8:17. I looked really nice up to that moment, though!


This was the intended route, but just before the TOC, the weather radar in the app suddenly changed massively. It looked nothing like the radar picture below, but I didn't capture a screenshot of it.
Screenshot 2024-04-22 201112.png
 

mmcmah

Active member
I did the same flight with the same historical weather again with the newest beta (8879). I didn't include any of the debug or conditions windows, but I did note that on the climb out, the Conditions window stated that it was cloning the conditions out of the departure airport. If anyone else wants to try this, here is the Simbrief briefing:
Screenshot 2024-04-23 142003.png
The route is WMKI/22 AGRE2B VPG Y350 RIGTO M769 DOXAS Y94 LOSDA Y95 IDRUK R588 KOS R334 PQU W8 RG RG1H VVCT/24

The Simbrief briefing was generated with a historical weather upload for 22 April 2024 at 0824Z.

The video can be found here. All looks great until the very end of the video (at the 7:30 mark, heading to VPG) when it suddenly transitions away from the departure clouds. Also, the log file is attached.

 

Attachments

mmcmah

Active member
I've now done two more flights that had the same result (the most recent one with the Conditions and Debug windows visible in the recording, if you would like it). I was trying different combinations of timing, opening, closing, etc. but very little difference. I will try without a flight plan next.
 

mmcmah

Active member
There does seem to be a bug with the transition when a flight plan is loaded.

Flying without a flight plan resulted in a more normal transition to different cloud cover. I have a (long) video of the flight if interested. Not only was the transition smoother, but the cloning of the departure airport didn't stick for as long as with a flight plan.

I think I may now drop the transition smoothing factor down from 50 even on 8879, though.
 

damian

Developer
Staff member
Thanks for the continued details. I am investigating the flight plan interaction on your route example above.
 

mat18590

New member
Thanks for the continued details. I am investigating the flight plan interaction on your route example above.
I think I understand why sometimes an immediate transition is made. It happens when you move to an area with different weather and the weather update is performed at the same time. In that case, regardless of the setting, an immediate transition occurs for the weather in the area
 

mmcmah

Active member
I think I understand why sometimes an immediate transition is made. It happens when you move to an area with different weather and the weather update is performed at the same time. In that case, regardless of the setting, an immediate transition occurs for the weather in the area
It's a good thought. I had it too on a different flight. It may well be part of the issue (and more broadly with transition timing), but I also think that in this case, the flight plan is causing the app to lock in the weather for longer than it should and then if it finds itself with widely differing weather, it immediately transitions to that depiction.
 

mmcmah

Active member
Thank you for the new build. I have now done three flights with 8880B, all using the historical weather and same route as I've previously indicated.

I will try to post a video later when I have time to go through the videos to pick things out. In the meantime, here are my observations about the current build (sorry about the length and about the fact that some ideas are still rough):
  • I realized that in order to minimize weather variations, I should start each flight at exactly the same time. The videos I've taken are have a variance of about 30-45 minutes).
  • The flight with a plan flight and the flight without a flight plan both resulted in similar transitions, so the flight plan specific issue seems to have been resolved.
  • However, as others have pointed out, the clouds often seem too white and bright. It seems that this is coming from the injection of too much haze (presumably for precipitation?). I will try to post a portion of one of the videos later, but after initial climb, coming out of the thunderstorms, I see overly bright clouds, which after a transition become more correct looking and less hazy.
  • The worst case scenario for transition timing seems to be thunderstorms and, even more so, the clouds that can appear at the same level as and close to the airplane. This could be made worse when the Prevent CB from injecting thunderstorms option is disabled.
  • In these cases, the initial transition (even at my 35 smoothing factor instead of the default 50) starts within seconds of the new theme being injected. Those closest clouds undergo changes first. While the total transition time might be 10-12 minutes, the most obvious transitions are almost immediate. What is the algorithm that changes the existing theme for the new one? What does it modify first and then how does it layer additional changes? Can it inject changes farther away first and then get closer to the plane, or does it start at current altitude, then low and then high?
  • It seems that the flight plan is mostly being used to determine the departure and arrival airports and the weather it's going to inject for those. It's quite likely doing more than that, but I haven't yet seen (in this version) a huge difference between not having a flight plan and having one.
  • Since some planes travel faster and higher (Fenix in my present case), maybe the algorithm (especially if there is a flight plan) needs to try to account for altitude and speed to examine the METARs en route along the planned path and determine the right weather to inject - on average - for the duration of an expected transition period.
  • I'm not 100% sure how to explain this suggestion, but it seems that the speed, altitude, download interval time length, the smoothing factor and the newly created injection timing between download intervals all need to work dynamically to come up with regular injection periods and transition timings such that full injections actually happen. Currently, if you have a smoothing factor less than 50, you may not ever get a full transition because of the new ~7 minute interim transition being injected.
  • The faster the plane the more likely you are to encounter differing weather conditions (for example rainy -> few -> rainy) and so with a more dynamic injection timing algorithm, and with a flight plan (or heading/speed/altitude projections of path), the program could decide, for example to inject only "rainy" in my example above. After all, it's every time a transition happens that you can see the changing weather.
I still need to better explain some of this, but hopefully the videos will help.
 
Last edited:

mmcmah

Active member
BRAVO @damian ! The latest build (8881) looks great. A TON of improvements. I ran my usual rest flight, changing the smoothing rate to the default 50 (up from 35 with the prior tests). Even that scenario resulted in a very good depiction of the changing storms and cloud cover. I still had some near cloud formation transitioning that, while controlled and understandable under the constraints that you have to operate under (and better than in the prior builds with smoothing rate 35), would be preferable not to see.

As such, I turned down the smoothing rate to 25 and I am currently halfway through the climb out. So far, it's SPECTACULAR! I will post a video as soon as I finish the climb out and get the video uploaded.
 

mmcmah

Active member
I decided to upload a full video of the climb out (Transition Smoothing Factor set to 25). Feel free to scrub forward. Here's the video:

.

My comments are below (if I don't call something out, I think it's looking really good):
  • The new turbulence effects (I have them all turned all the way up) are much better than before.
  • At 00:39, breaking out of the storm over the airport, you can see the rain cloud bottoms. As others have said, these tend to look a little flat and linear on the bottom, but maybe that is the way they are supposed to look.
  • At 10:30, the transition away from Thunderstorms and to Showers begins. Again, given the limitations imposed by MS/Asobo, these look good even though they are noticeable and start as soon as the transition begins.
  • At 12:08, there are a lot of CB columns up ahead; I know from flying through the weather so many times that the METARs in ahead of here are going to be reporting showers and starting to clear, so these will present a problem (these can be eliminated by turning on the Prevent Thunderstorms when CB Reported option, but the sky looks much better with the columns!
  • The Thunderstorm columns start collapsing (gone by 13:43) quickly at that point, since the METAR is now reporting showers.
  • The gradual clearing from there for a bit is accurate and looks good (this is the area where the 25 transition factor likely obscured a greater clearing, but since the plane was moving into heavy weather again, it seemed like a good thing that it retained some of those showers for longer.
  • The problem is that at 23:19, the Conditions are now reporting Thunderstorms, which means that the CB columns are soon going to appear nd build up again. This starts happening at 26:24, after a new weather download.
  • As I've said before, I get the limitations that give rise to these transitions, but in two minutes to 28:19 (with a 25 smoothing factor), those columns are now filling the cockpit window.
  • One minute later (29:16), the conditions shift to Cloudy and soon the columns that just arose, will shrink again (at 31:09 the conditions shift to Showers before the transition away from the columns has started). The shrinking of the columns starts at 33:20 and takes about a minute for them to disappear into Partly Cloudy.
  • Overall, given I thought the weather depiction looked great. Clearly a quicker transition smoothing factor will yield a more faithful representation of the weather conditions as you go, but the need for faithfulness needs to be balanced with transitions that aren't jarring.
  • The haze/humidity in the background especially at the very end, might be correct, but if not, seems like it can make the horizon area overblown.
One final usability comment. The historical weather interface immediately implements whatever you put in. That is not too big a problem because it restarts the downloads whenever you change the date/time. However, the issue arises if you change the time by a small enough amount that you are still in the same hour as the original download of weather data (0800Z or 0900Z, for example). This causes the time that it shows on the status bar to not change versus the original time when you started that weather data download because it thinks that it doesn't have to download again and it can simply continue as is. If there were an Apply button to actually select the date/time and start the download, that issue could be ameliorated. This has been the cause of a lot of the time de-synchronization of the videos I have been trying to capture.

The issue with the CB/Thunderstorm columns can be greatly reduced by by selecting the Prevent Thunderstorms when CB Reported option, but as I said before, the sky looks better with the larger storm clouds, because otherwise the clouds tops aren't as dramatic.
 
Top