gwicke
commented
3 months ago From what I can tell, windy's level data as returned from the API does not seem to be scaled to model elevation. My understanding is that models usually "compress" layers to follow the geography: https://confluence.ecmwf.int/display/CKB/ERA5:%20compute%20pressure%20and%20geopotential%20on%20model%20levels,%20geopotential%20height%20and%20geometric%20height
So a model 1000h level might actually correspond to fairly high geometric elevations in mountainous areas, and post-processing is required to relate it to geometric elevation. I do not think this post-processing has been done on the windy side.
The default soundings plugin seems to do some elevation re-scaling client side, but it does so inconsistently. For ECMWF it seems to work alright, but for HRRR and NAM for example, this re-scaling does not seem to happen at all. Forecasts for points with high modelElevation show a sounding starting just above sea level.
The way I read the code, this plugin seems to mainly hide lower levels up to forecast elevation, basically hiding lower boundary layer data with the "surface" box.
I did some experiments with a python script, trying to figure out ways to scale lower boundary layer data:
- Treat model geopotential height at relative to modelElevation. Re-scale linearly to the interval [modelElevation, 150h] level (not sure if linear is correct).
- Lapse temperature and dewpoint predictions with 0.65C/100m to scaled altitudes. Do not lapse surface predictions.
At first view, the results look believable, with smooth transitions from surface forecast to low boundary layer temperatures, and rough agreement in higher layers as well.
Do you have a recommendation for a ground truth for soundings that could be used to verify elevation handling? One site I am aware of for NOAA models including GFS & NAM is https://rucsoundings.noaa.gov/gwt/, but even there elevation handling is inconsistent. RAP uses location elevation, while GFS and NAM are displayed at 1000h even in areas with high elevation.
While looking into super-adiabatic surface heating in desert / hot and dry regions (as an indicator for especially sharp thermals near ground), I noticed that the near-ground temperatures shown in this plugin differ from those in the stock windy soundings view.
Example, using a dry desert location mid-day, ECMWF model:
https://www.windy.com/sounding/32.259/-111.661?clouds,32.259,-111.661,10,i:pressure
https://www.windy.com/plugin/sdg/32.258/-111.662?clouds,32.259,-111.662,10,i:pressure
The windy stock soundings view has ECMWF predicting a super-adiabatic layer near ground level (up to ~800m). This plugin shows the opposite, a relatively weak lapse up to ~700m, and more above. The max temperature at ground level is higher in the windy default sounding, and in that case agrees with the values shown in the regular point forecast view.
Interestingly, at least in some spot checks for sunny locations it seems that taking the parcel lapse for the higher predicted max temperature yields a top of lift prediction not that far from the static +3C assumption used in this plugin. I am wondering if using the predicted ground temperature as a base (potentially with a smaller static offset) would improve the consideration of cloud cover and other effects covered by the weather models.
I am curious about the background and potential thinking behind how near-ground temperatures are handled in this plugin. If there is consensus that aligning the temperature handling with the default soundings could be worthwhile, then I could potentially help with diffs.