And another issue with resetting. When you click somewhere on the map it resets the position of the map so that the clicked location is in the centre. This is a problem if you click near the edge of the areas of a particular model, because the map recentres on the point, then the model switches to another model because it considers the view to be outside the range of what is applicable for that model.

For example, choose ICON-D2, sounding, then click on Gloucester in the UK. The map scrolls so that Gloucester is in the centre of the non-sounding part of the map, then the model switches to ICON-EU. (I think it is using the centre of the whole screen - including the portion of the map that is hidden by the sounding pop-up - to determine whether the model can be used. So you have two inconsistent definitions of centre.)

One more vote for scrolling through the timeline on mobile.

Also can we have an option for the green dotted line for thermals to be drawn automatically based on the actual surface temperature and surface dew point? This should really be the default. It is rare to want to know what a parcel of air would do if released into the atmosphere with some random temperature and random humidity.

When showing the forecast sounding for a mountain region, the vertical axis begins at a pressure less than 1000hPa, corresponding to whatever the ground level pressure is. For a low-lying area, the vertical axis beings at 1000hPa, never higher, which is wrong. It appears that the calculated LCL and CCL are also wrong because of this.

For example, get the sounding for Mont Blanc. The vertical axis starts at something like 750hPa / 2300m (the model elevation is 2300m even though Mont Blanc is 4809m -- this is not the problem). To get the correct LCL, position the cursor so that the dashed green thermal line and the grey line of constant mixing ratio intersect the red environmental lapse rate line and blue dew point line respectively. The height of the cursor is displayed on the vertical axis correctly and corresponds to the LCL shown below the graph.

If you do the same for Monaco on the sea, the vertical axis starts at 1000hPa. The lowest altitude that can be displayed on the sounding is typically a few hundred metres (depends on the surface pressure). So even if there is fog/cloud on the ground/sea (dew point temperature and environment temperature is the same), the displayed LCL is a few hundred metres, instead of 0 (sea level). This is wrong.

I imagine the fix is very simple. The vertical axis should be allowed to start above 1000hPa as well as below. It seems to be clamped to 1000hPa for some reason.

@vicb am I right to mention you on this issue? Hope you can help or redirect. Sorry if that was inappropriate.

Just a screenshot to help demonstrate the issue. The location is on the sea with pressure 1023hPa and humidity close to 100%. The sounding should start at 1023hPa but it starts at 1000hPa. The LCL should be close to 0m (sea fog) but it is 204m.

It would be good if the zoom/scroll of the sounding window didn't reset either. This makes it hard to compare soundings for different spots. (As a paraglider pilot, I want to be able to look at the soundings for different parts of the country to help make a decision which site to go to.)

Since today, when viewing windy.com on my laptop with Firefox (Ubuntu 21.10), the mobile version of the page is being shown. The mobile version doesn't work on desktop since it requires touch interactions which the mouse seems not to trigger. This is despite deleting all cookies and clearing the cache. Same on private window. Same logged out. On Chrome, the desktop version of the page is correctly shown.

Have you recently changed a version-detection string regex perhaps?

When you drag the time slider to, say, 15:00, you may get shown the data for 15:00 or 16:00 depending on exactly how far you slide it. Looks like a basic rounding error to me where the data for the position of the slider is rounded to the nearest hour in two different ways, one for text display on the slider, and two to decide which data to display on the map.

Very easy to reproduce and has existed as long as I can remember using Windy, so I'm not sure why it hasn't been noticed by the developers unless there's something more subtle going on.

Just want to highlight this bug again. I forgot to say the mobile platform is Android. No idea about iPhone. Tested on two devices. This is a major bug. Windy is fantastic in general.

Sorry for the delay replying. I have attached a screenshot but the bug is very easy to reproduce without. Tested on two phones. Surely wrong every Android phone.

The image shows two screenshots which both say "13:00" on the time slider, but the data shown is different for both. To be clear, the model has not changed, nor anything else besides moving the time slider. The only difference is that the second image has the time slider moved towards the end of the hour.

Basically every time a user looks at a forecast in the future, there's a 50/50 chance the data displayed will be wrong. This is an enormous bug and probably very easy to fix. I would guess that the code for getting the time from the slider is duplicated in two places, one using round, one using floor.

@Ondřej-Šutera sorry I missed your reply. I have updated my notifications settings to email me so I shouldn't happen again.

I could provided another screenshot but I'm not sure it will help you replicate it. I have been using Windy several times per week for the last few years and this bug has always existed. It happens on every model for every layer for every part of the map. It happens on my phone (Pixel 3a) but also the one other Android phone I have tested it on so far (Oppo Find X5). My timezone is Europe/London in case that matters.

Is it possible that the time slider is doing some calculation based on screen width that is being unreliably calculated? (I know getting window dimenions in a browser/WebView can be error prone.)

What is definitely true is that the logic to determine what time to display on the time slider is not the same logic to determine what time of data to fetch and display on the map. Even if you can't reproduce, I would guess that you would be able to verify this in code.

How can I best help you investigate this further - provide more screenshots or a video, or get a list of more devices that are affected, or something else?

Version is currently 39.3.2.

@nrbray sounds like you and Tom know at least as much as me.

As I understand it, both soundings use temperature and dew point from 1000hPa as the basis of LCL, CCL, green thermal line, cloud base, and cloud tops. I believe this is wrong and gives incorrect data. On the other thread I gave an example of 100% humidity at sea in a high pressure location where the LCL should be 0 but it was 204m, and the same error in the plugin (no screenshot). (I don't know what the calculation is when the pressure is less than 1000hPa, though this is uncommon for me personally.)

It seems to me it would be better to switch to some kind of surface data even before it's clear which is strictly correct to use. I know Victor is sceptical about using surface data, but I'm not sure if he agrees that using 1000hPa temp/dp is wrong.

Windy haven't acknowledged much simpler bugs elsewhere for me so I don't wait for any change to the sounding unfortunately.

@vicb thanks for investigating.

I hope the temp-surface data can be used. If not, the green thermal line and cloud prediction would have to be removed from the plugin completely, right? Also I think the built-in sounding would have to remove the LCL and CCL.

You suggest the surface data may be the soil and not the air above the surface, but I don't think this is true. Regardless, if it is valid, is there any data missing or is it still possible to calculate the points on the diagram? The plugin just shows heights; are these heights just calculated from temp-1000h, temp-900h by assuming ISA? Can the model elevation be used for the surface data? (The builtin sounding shows the model elevation, but perhaps the plugin doesn't have access to this?)

I've taken some screenshots of 4 other weather websites for how they do soundings:
https://drive.google.com/drive/folders/1176-cdivdmWwW4vaguJmydc5Uir2Cs0H

They include:

• meteoblue (https://www.meteoblue.com/en/weather/aviation/stuve)
• weather.gov (https://www.weather.gov/zse/ModelSounding)
• ECMWF (https://charts.ecmwf.int/products/opencharts_vertical-profile-meteogram)
• Weather Online (https://tinyurl.com/2f35xkae)

The Meteoblue temperature and dew point lines always starts at 1000hPa, and it also shows a horizontal surface pressure line. All the other examples start at the surface pressure, whatever that is for the particular location and time.

@vicb fantastic!

@vicb I don't know Redux and can't follow through the code but I see something about pMax: 1000 in src/reducers/skewt.ts in the code for the plugin. Is this the right area of code? Do you think you might get a chance to look at this in the plugin? And/or do you know who to mention from the Windy team who might be able to make the corresponding change in the built-in sounding?

The sounding is amazingly useful and it's great that this is available for us pilots so easily in Windy.

I believe sometimes it goes forward 3 days and sometimes 5 days and it's switching between the two. I'm not sure the exact times but one is about 2 days longer than the other. Just an idea: is the API for UKV giving a more recent update that doesn't go as far forward in time that stops us seeing an older 5 day one? I have premium (updates every 6 hours) in case this is relevant to the behaviour.

@Korina @Suty I see you comment on the original UKV thread so hope it's okay to mention you here.
https://community.windy.com/topic/24400/the-ukv-met-office-model-is-now-available-on-windy

Just a screenshot to help demonstrate the issue. The location is on the sea with pressure 1023hPa and humidity close to 100%. The sounding should start at 1023hPa but it starts at 1000hPa. The LCL should be close to 0m (sea fog) but it is 204m.

@Suty sorry again for the late reply.

If you are experiencing the issue in the same way as me, no I don't agree the issue is minor. The time shown on the time slider must correspond to the data shown. If you slide the time until it says 4pm and it shows you the data for 5pm, it's simply wrong.

I wouldn't say it's an issue of pixels either. Programming wise, whatever code takes the position of the slider and rounds it to the nearest hour should be used both to determine what data to display and also to determine what time to show. It sounds like the same calculation is being done twice in two separate places with separate logic.

It would be great to see this fixed.

@vicb Ah, my mistake, I thought you wrote the builtin sounding after writing the sounding plugin.

I think the sounding plugin shows the same behaviour though. If I find a high pressure area on the sea, the sounding plugin does not start at 0m. But if I find a low pressure area less than 1000hPa on the sea, the sounding plugin does start at 0m. For a mountainous location, the sounding plugin starts at the model elevation (as reported by the builtin sounding).

So it appears both the builtin sounding and sounding plugin have the same behaviour.

@vicb fair point that multiple altitude levels is inconvenient. I think you're right.

What I wanted was some indication of thermal strength, however crude. I have been eyeballing the sounding to see how superadiabatic the lowest bit of the atmosphere is. The thermal layer gives height but I'm not comfortable using it without an explanation of the algorithm.

Thanks for the tip on colour scales.

When showing the forecast sounding for a mountain region, the vertical axis begins at a pressure less than 1000hPa, corresponding to whatever the ground level pressure is. For a low-lying area, the vertical axis beings at 1000hPa, never higher, which is wrong. It appears that the calculated LCL and CCL are also wrong because of this.

For example, get the sounding for Mont Blanc. The vertical axis starts at something like 750hPa / 2300m (the model elevation is 2300m even though Mont Blanc is 4809m -- this is not the problem). To get the correct LCL, position the cursor so that the dashed green thermal line and the grey line of constant mixing ratio intersect the red environmental lapse rate line and blue dew point line respectively. The height of the cursor is displayed on the vertical axis correctly and corresponds to the LCL shown below the graph.

If you do the same for Monaco on the sea, the vertical axis starts at 1000hPa. The lowest altitude that can be displayed on the sounding is typically a few hundred metres (depends on the surface pressure). So even if there is fog/cloud on the ground/sea (dew point temperature and environment temperature is the same), the displayed LCL is a few hundred metres, instead of 0 (sea level). This is wrong.

I imagine the fix is very simple. The vertical axis should be allowed to start above 1000hPa as well as below. It seems to be clamped to 1000hPa for some reason.

@vicb am I right to mention you on this issue? Hope you can help or redirect. Sorry if that was inappropriate.