The Candian model is actually very good, and just as free and available as GFS. It outranked GFS in accuracy, at least in the last article I read. I'd love to find a better source of accuracy-ranking for NWP models if anyone knows of one. Also, the UK Met Office have now started putting the output of their Unified Model on AWS. The UM ranks just behind ECMWF, it's a great model. The data on AWS is 24 hours behind, but this shows their progress in data dissemination. Not sure what costs would be involved but check out this as an FYI:

https://github.com/MetOffice/aws-earth-examples/blob/master/README.md

As far as AROME vs HIRLAM, I'd say AROME is the way to go :)

Haha thanks @rittels! Seems the only issue was my impatience. It's working now. :)

@ivo thanks for the info. It turned out to be quite trivial :)

The timestamp call works a treat. With the loader: no, there was no error, but I was embedding one load statement within the other which was probably a bad idea. I found a better approach by looping through the forecast keys and creating a time series array of surface pressure. Works nice now.

I also added a call to store.get('product') so that I could load the current model, and I think I've found a bug on your end. If you change model from ECMWF to GFS and vice versa, the output of store.get('product') shows the old model. You have to move the picker before it will show the highlighted model.

One other thing: how can I get the latest version to show in the plugin loader? If you enter windy-plugin-skewt you get version 0.1.0, the first version. You have to enter windy-plugin-skewt@0.2.5 to get the correct one. Obviously, this isn't a windy thing, it's to do with unpkg and npm. But any idea how to fix it? Npm shows me the latest version on its website, but I have to add the version number in unpkg.com to get the right one.

Perhaps those of us who loved the 3D mode were too silent about it! I would also love to see its return :)

Yep, 10m.

Most airports and met stations will have a 10m mast, but when you're short of one, there is a formula you can use to (crudely) account for the drag due to being closer to the Earth, and therefore calculate the 10m based on the 2m wind.

Do also bear in mind that it SEEMS like the NWP forecast is always wrong, but try watching it consistently for a few days. In some areas (where terrain, ocean, etc. do not create significant biases that the resolution can't cope with), it can be scary accurate.

Much love Lewis F. Richardson ✌️

Version 0.2.0 is done! The skewT plugin now runs with ECMWF data. Use the picker to open a skewT and explore the world's profiles :)

This version is still a little buggy I'm afraid (mostly the wind barbs), but I'll publish a few fixes soon. It's also slower than I'd like. Two things that would really help me for the next version are

1. Is there a simple way to get surface pressure? I've tried getting it from the "forecast" method of pluginDataLoader, but using both this and "airData" together seems to grind everything to a halt. Right now the plugin just uses 1000hPa as the surface, which is far from ideal. Any chance someone @Windy could add surface pressure into the "airData" on the backend?

2. Is there an API call that is sensitive to user changes in the time slider? Right now you have to move the picker after changing the date/time, or the plugin can't reload itself. Couldn't find anything in the API docs that could do this.

Cheers!
John

@ivo @rittels @Gkikas-LGPZ

@ivo great to see the plugin loader is ready for model data. I'll look into updating the skewt plugin when I get a chance (bit busy at the moment though).

There was a bug in my plugin that showed the error "TypeError: Plugin.instance is not a function" and you fixed this. Can you remember what the bug was? I'll need to patch in the fix to my original version.

@rittels Sure, though I'd say nearest neighbour is plenty for now! Vertically there is some interpolation going on in the js, and horizontally, ECMWF's 9km is loads of detail :) Would definitely be a nice addition for later.

@ivo Windy appears to use pressure levels from ECMWF, with temperature, humidity, and wind at each of these levels already available on the site. So what needs to be done on your backend is to have a function that takes a lat/lon picker point as input, finds the nearest grid point on the model, and then finds the data at each of these pressure levels. You might be able to adapt this from my closest_latlon() function in plugin.html. The variable Pascent (the ascent data for P) will always be:

Pascent = [ 1000, 950, 925, 900, 850, 800, 700, 600, 500, 400, 300, 250, 200, 150 ]

Though I see you also use "surface" and "100m" instead of 1000hPa, so by all means use that if you also have temperature and relative humidity at those levels.

Then Tascent is the temperature (shortname is "T" in the ECMWF docs), U is the U-velocity (shortname "U"), V is the V-velocity (shortname "V").

One thing I'm now realising is that I used an equation to convert the humidity into the dewpoint while generating the sample data, so you'll need to add this into plugin.html. To get Tdascent (the dewpoint temperature ascent), relative humidity (shortname is "R" at ECMWF, and the Windy is named "Humidity") must be converted to dew point using this formula:

for (var p = 0; p < Pascent.length; p++) {
Tdascent[p] = 243.04*(Math.log(R[p]/100)+((17.625Tascent[p])/(243.04+Tascent[p])))/(17.625-Math.log(R[p]/100)-((17.625T)/(243.04+T)))
}

@ivo - Brilliant! I'm chuffed to see it working on the site :) Let me know if you need any help understanding the code. You just need to load the variables Tascent, Pascent, Tdascent, U, and V with spot data at each level. The comments should hopefully explain this.