WXBELLS SNOWFALL EURO MAPS... dont make much sense

[DTWXRISK]

I am  beginning to think the snow maps   ecmwf over at   WXBELL are  not very good.  I mean  they  have amazing   detail and are   works of  art   but last winter a lot folks  got burned by looking at their snow  maps . I  am  beginning  wonder of    maybe this is  not on the up and up...

 

For example     looks at the 0z   monday  EURO.  This map from   SV   CLEARLY   shows even though 850 temps  on the 0z  monday  ecmwf go above 0 at NYC   PVD and  BOS  ...

 

 

 

the Euro snow maps over at wxbell has BOST  getting 12 to 14" of snow and NYC PHILLY BWI DCA seeing 6" .   Given how the 0C 850 isotherm goes NORTH of NYC and BOS   I dont see how wxbell snow maps make any sense. 

 

Yet the  0Z EURO SNOW MAP....    from  EUROWX.com  admittedly at  0.5  resolution...   has MUCH LESS SNOW .... 1"   for BOS NYC  PHL  and use the  Evan  Kuchera  algorothim

 

hmmmmmm

 

[donsutherland1]

 

I am  beginning to think the snow maps   ecmwf over at   WXBELL are  not very good.  I mean  they  have amazing   detail and are   works of  art   but last winter a lot folks  got burned by looking at their snow  maps . I  am  beginning  wonder of    maybe this is  not on the up and up...

 

the Euro snow maps over at wxbell has BOST  getting 12 to 14" of snow and NYC PHILLY BWI DCA seeing 6" .   Given how the 0C 850 isotherm goes NORTH of NYC and BOS   I dont see how wxbell snow maps make any sense. 

 

Yet the  0Z EURO SNOW MAP....    from  EUROWX.com  admittedly at  0.5  resolution...   has MUCH LESS SNOW .... 1"   for BOS NYC  PHL  and use the  Evan  Kuchera  algorothim

 

 

I'm not sure what the issue is with the WxBell maps, but it seems that the underlying assumptions might be that all precipitation that falls as snow accumulates at a given ratio regardless of surface temperature, snow growth, etc.

 

With the forecast storm, the 11/24 0z ECMWF shows the heaviest precipitation having fallen when the 850 mb temperature moved above 0°C in Boston. Moreover, during a large part of the event, the surface temperature is in the 1°-2°C range meaning that some share of the snow would melt upon falling. NYC also has similar issues. A slushy coating to an inch in NYC and several slushy inches in Boston would seem closer to the actual outcome given the data than  6" in NYC and 12"-14" in Boston based on the 0z ECMWF. The EuroWx.com maps seem more realistic, IMO.

[packbacker]

 

I am  beginning to think the snow maps   ecmwf over at   WXBELL are  not very good.  I mean  they  have amazing   detail and are   works of  art   but last winter a lot folks  got burned by looking at their snow  maps . I  am  beginning  wonder of    maybe this is  not on the up and up...

 

For example     looks at the 0z   monday  EURO.  This map from   SV   CLEARLY   shows even though 850 temps  on the 0z  monday  ecmwf go above 0 at NYC   PVD and  BOS  ...

ECMWF_MSLPThickQPF_ne_f72.png

 

ECMWF_MSLPThickQPF_ne_f78.png

 

 

the Euro snow maps over at wxbell has BOST  getting 12 to 14" of snow and NYC PHILLY BWI DCA seeing 6" .   Given how the 0C 850 isotherm goes NORTH of NYC and BOS   I dont see how wxbell snow maps make any sense. 

 

Yet the  0Z EURO SNOW MAP....    from  EUROWX.com  admittedly at  0.5  resolution...   has MUCH LESS SNOW .... 1"   for BOS NYC  PHL  and use the  Evan  Kuchera  algorothim

 

hmmmmmm

 

0zeuro.png

 

 

When you look at the text output for Boston on EuroWx it shows 6.1" of snow but the snow map obviously shows much less.  It must be taking into account melting due to BOS's 2m being over 32.

[DTWXRISK]

CORRECT

 

When you look at the text output for Boston on EuroWx it shows 6.1" of snow but the snow map obviously shows much less.  It must be taking into account melting due to BOS's 2m being over 32.

[GaWx]

Another issue with Euro (including ensemble) snow maps (this issue not restricted to just WxBell as we
discussed in the SE forum a whole lot last winter) is that the Euro for whatever reason is unable to distinguish between SN, IP, and ZR! Whenever it has the surface at 32 or less, the Euro snow map counts ALL precip. as accumulating SN! So, say there is a CAD with the surface at 31 but 850's at +5C and with 1" of qpf. The Euro would show 10" of SN on its clown map instead of what actually would be 0"! Time and time again the Euro clown maps would show multi-inch snow accumulations with 850's clearly above 0C! I called my provider about this last winter and they were able to confirm to me that the Euro is unable to distinguish between SN, IP, and ZR in the data that goes into the snow accumulation maps! The irony is that the GFS is actually superior to the Euro in this case as its clown maps are able to distinguish. I can't recall ever seeing GFS snow maps showing any snow accumulation when 850's were above 0C.
Has anyone else noticed this Euro problem with ZR and IP? In the SE, this is probably more noticeable due to a higher % of wintry precip. not being SN vs., say, the NE US.
Again, this particular problem with ZR and IP is definitely NOT restricted to WxBell maps. As a result of rather extensive discussions on this last winter, many in the SE forum are now fully aware of this issue.
Meanwhile, these Euro clown maps got posted a whole lot on social media last winter and lead to the spread of a lot of misinfo about snow predictions in the SE US. This included the mid Feb storm that gave much if the SE a wintry mix. There were several Euro runs with snow maps showing over a foot of snow in Atlanta even with 850's ABOVE 0C for most of the storm (only the end below OC.) Atlanta ended up with "only" a few inches of accumulation with much of the accum. being IP and with lots of ZR falling mainly E and S portions of the area.

[ezweather]

Definitely agree with DT.  Curious why Ryan hasn't addressed this issue. I have F5 Weather data, which is the other site and its totally different based on what they do with the data.  For what they charge, there's no excuse to present snow maps like this, which can be really misleading.  Definitely needs to be addressed.  

[GaWx]

Definitely agree with DT. Curious why Ryan hasn't addressed this issue. I have F5 Weather data, which is the other site and its totally different based on what they do with the data. For what they charge, there's no excuse to present snow maps like this, which can be really misleading. Definitely needs to be addressed.

However, please keep in mind that the issue with Euro snow maps (at least as of last winter) is not restricted to WxBell as per my post above. At least part of the overall problem is related to its false treatment of ZR/IP though this latest situation may very well have nothing to do with ZR/IP. My provider is a major provider and even their Euro snow maps had big problems last winter even though their GFS snow maps didn't have that problem. I suspect there are multiple issues with Euro snow maps, with some of the problem with the Euro data, itself. WxBell Euro maps may be worse than others but that isn't the only provider issuing false Euro snow maps.

[ezweather]

However, please keep in mind that the issue with Euro snow maps (at least as of last winter) is not restricted to WxBell as per my post above. At least part of the overall problem is related to its false treatment of ZR/IP though this latest situation may very well have nothing to do with ZR/IP. My provider is a major provider and even their Euro snow maps had big problems last winter even though their GFS snow maps didn't have that problem. I suspect there are multiple issues with Euro snow maps, with some of the problem with the Euro data, itself. WxBell Euro maps may be worse than others but that isn't the only provider issuing false Euro snow maps.

 

Wow, didn't realize how much of a problem this on other sites.  Then I guess Ryan probably knows whats going on.  Well, as they say, be thorough in looking over these snowfall maps... Thats something we all need to do as we head into the winter..

[Shawn]

This has been a gripe over in the Southeastern forums for quite a while.  I can only imagine how horribly some of them turn out up the MA/NE.

 

Long story shot, I am not sure what is stopping them from rewriting their grads script to not use the 850MB line to determine winter weather or not.  Their ptype script could use a series of checks at the surface, BL, etc. to basically fix it.

 

Here is something I had posted a while back with a step towards a solution: (of course it'd be a bit more meteo advanced and the #s I used are just examples.

 

Through scripting, these vendors could make their Euro snowfall data more correct.

 

Basically, even if the raw output is "show snow on 32F temps", you can basically write a script in something such as GRADS like:

 

If surface temp + bl temps are <=32 and 850mb <=0c then

print snowfall

else

if surface temp <=32 and 850mb >= 1c then

print ice/mix/sleet etc etc

 

A problem, is ratios would have to be programmed in also.. depending on temps... but a lot of maps are all assumed at 10:1 anyways.  Math can be done on the side to come up with better amounts.

 

Edit: here is a thread where some of this convo took place not too long ago: http://www.americanwx.com/bb/index.php/topic/44204-2014-15-winter-outlook/page-10

[Shawn]

Definitely agree with DT.  Curious why Ryan hasn't addressed this issue. I have F5 Weather data, which is the other site and its totally different based on what they do with the data.  For what they charge, there's no excuse to present snow maps like this, which can be really misleading.  Definitely needs to be addressed.  

 

Andrew's EuroWX website is much more conservative (for the better) with snowfall amounts and is proof that some of these other websites are just using the 850mb 0c/32F to determine rain or snow on their snowfall output.

 

Also, Ryan is well aware of the issue.

[Cory]

The model produces output fields of actual snowfall (field name snow_fall_water_equivalent). Are these just not made available to users?  Maybe those files are only in the "both arms and both legs" package. 

[GaWx]

The model produces output fields of actual snowfall. Are these just not made available for users? Maybe those files are only in the "both arms and both legs" package. 

 

 I have the "both arms and both legs" package from my provider (actually that's all my provider has and they aren't cheap to say the least) and it still had the flawed Euro snow maps last winter when there was ZR/IP! My provider pretty much claimed that its hands were tied and that it was up to ECMWF, themselves, to correct this situation. At the same time, their GFS snow maps don't have the same problem! Mark Ellinwood knows about this as we discussed this publicly here at American.

 Shawn's solution makes sense and we discussed it last winter as well as this fall as he said.

[heavy_wx]

 I have the "both arms and both legs" package from my provider (actually that's all my provider has and they aren't cheap to say the least) and it still had the flawed Euro snow maps last winter when there was ZR/IP! My provider pretty much claimed that its hands were tied and that it was up to ECMWF, themselves, to correct this situation. At the same time, their GFS snow maps don't have the same problem! Mark Ellinwood knows about this as we discussed this publicly here at American.

 

 Anyone who gets the raw ECMWF grids is getting 4D temperature and humidity fields, along with precipitation (water equivalent for snow/ice and rain) could produce a more intelligent algorithm for determining P-type at the surface. Even if all they received were those variables at every 50 mb, a decent (or at least more accurate) model SWE wouldn't be that difficult to make.

[Shawn]

 Anyone who gets the raw ECMWF grids is getting 4D temperature and humidity fields, along with precipitation (water equivalent for snow/ice and rain) could produce a more intelligent algorithm for determining P-type at the surface. Even if all they received were those variables at every 50 mb, a decent (or at least more accurate) model SWE wouldn't be that difficult to make.

 

Yes, WxBell uses grads scripts to generate the output.  Things can be modified around to just make custom snowfall maps if it was warranted off the raw data.  I haven't seen the raw data from the Euro, but if it is a "package" type system (variable) that vendors are using, then the model is broken.

 

I can't see the Euro guys having a skewed snowfall output by default though.  These computer models are very advanced and the people who work with them are nothing less than rocket scientists it seems.  I can't see this being an oversight in the model itself's variables.

 

I've personally worked with Grads and a little Gempak scripting.  It can be done.  It may slow the model output out a bit and create another round of data analysis/cpu power depending though.

 

 

In fact, the EuroWX site that Andrew has (F5 Data guy) seems to do it right... and I'm almost 100% sure he uses GraDs.

[Cory]

Yes, WxBell uses grads scripts to generate the output.  Things can be modified around to just make custom snowfall maps if it was warranted off the raw data.  I haven't seen the raw data from the Euro, but if it is a "package" type system (variable) that vendors are using, then the model is broken.

 

I can't see the Euro guys having a skewed snowfall output by default though.  These computer models are very advanced and the people who work with them are nothing less than rocket scientists it seems.  I can't see this being an oversight in the model itself's variables.

 

 

 

My guess would be a post-processing technique rather than a model flaw. ECMWF might be using a bulk method; where if just over 50% of the precip produced by the microphysics scheme is snow, it considers all the precip to be snow at that timestep and dumps it into the snowfall bin. In a borderline situation, that might cause snow to appear when other p-types are actually occurring. 

[GaWx]

MDA/Earthsat is my provider and they're way more expensive than WxBell. Yet, they claim their hands are tied. I would have thought they could come up with a simple program similar to what Shawn suggests to modify the snow maps. However, the way they were talking, that wasn't a viable option for them. I actually called them about this and we discussed it.

 As I said, their GFS snow maps don't have the problem. Why is that? That's why they're blaming ECMWF, itself.

 

To be clear, the Earthsat (and other) Euro snowfall maps aren't just generating snow in borderline situations. They're doing it even when, say, 850s are like +5 C+ if the sfc is 32 or lower!

[bdgwx]

Anyone who gets the raw ECMWF grids is getting 4D temperature and humidity fields, along with precipitation (water equivalent for snow/ice and rain) could produce a more intelligent algorithm for determining P-type at the surface. Even if all they received were those variables at every 50 mb, a decent (or at least more accurate) model SWE wouldn't be that difficult to make.

Agreed. I don't know why more sites don't adopt a thermal profile scheme (like the Air Force/Kuchera or Cobb methods). So far the only sites that I know use the AF method are WxCaster, Instant Weather Maps, and HopWRF.

[Ellinwood]

I imagine there's multiple reasons why map distributors have the Euro snow maps the way they do:

1) To be consistent about how snow is handled (in post-processing) across all the models they show.

2) The additional computations in post-processing = slower map output, hurting the companies that compete with others in being the fastest map producers.

3) They don't think that there is enough of a payoff to put the time and effort into creating additional post-processing procedures.

[weatherwiz]

The best thing that can be done with model output snowfall graphics is to destroy them.  Just eliminate them.  I really don't see the point to them except to be tossed around and used irresponsibility.  I suppose you can make an argument that it's just a tool for forecasters as perhaps a reference or something but IMO they just don't do any good.  For anyone who forecasts, there are numerous data sources and numerous outputs available that a forecaster can use to come up with a very sensible forecast using his/her's abilities and talents.  

[Cory]

I was comparing today's 12Z WxBell Euro total snowfall map to the Euro snowfall in AWIPS and on EuroWx. They were similar until Dec 4th, when a 6-10" strip of snow appears from western Oklahoma through eastern Kansas and into Iowa on WxBell. AWIPS and EuroWx have no such thing. 

[GaWx]

I was comparing today's 12Z WxBell Euro total snowfall map to the Euro snowfall in AWIPS. They were similar until Dec 4th, when a strip of snow up to around 10" appears from northern Oklahoma across eastern Kansas on WxBell. The Euro in AWIPS had no such thing. 

 

Cory,

 My provider, Earthsat, also has something screwy. They have ~4-9" of snow ~12/4 from northern OK to E KS in an area where the 850's are well above 0C...like +4 to +6 C. However, the two meter temp.'s are near or just below 32. So, this must be ZR and perhaps some IP.  As I was told by Earthsat, the Euro snow maps treat ZR and IP liquid equivalent like SN. This is not just a WxBell problem by any means and it has been going on since at least last winter.

[Cory]

Cory,

 My provider, Earthsat, also has something screwy. They have ~4-9" of snow ~12/4 from northern OK to E KS in an area where the 850's are well above 0C...like +4 to +6 C. However, the two meter temp.'s are near or just below 32. So, this must be ZR and perhaps some IP.  As I was told by Earthsat, the Euro snow maps treat ZR and IP liquid equivalent like SN. This is not just a WxBell problem by any means.

 

I edited to add a mention of EuroWx after you'd quoted my post. Their map looks very similar to what's in AWIPS, with no OK/KS snow. If this problem originates at ECMWF, it wouldn't make sense for some providers to have anomalous snow and others not. 

[GaWx]

I edited to add a mention of EuroWx after you'd quoted my post. Their map looks very similar to what's in AWIPS, with no OK/KS snow. If this problem originates at ECMWF, it wouldn't make sense for some providers to have anomalous snow and others not. 

 

 Maybe EuroWx and AWIPS have written a program, similar to what Shawn suggested, to modify the erroneous snow map output? Perhaps, Earthsat and WxBell don't have any such program.

 Also, as I said yesterday, the Earthsat GFS snow maps never have this problem. So, the relevant raw GFS data appears to be more accurate.

[Cory]

 Maybe EuroWx and AWIPS have written a program, similar to what Shawn suggested, to modify the erroneous snow map output? Perhaps, Earthsat and WxBell don't have any such program.

 Also, as I said yesterday, the Earthsat GFS snow maps never have this problem.

 

That would have to be why since there's an inconsistency. I find it strange that the programmers of a sophisticated model like the Euro would make such basic mistakes with ptype and allow it to continue. I haven't been able to find anything online about how the model handles ptype, etc. Unlike NCEP, ECMWF doesn't seem to lay out its model's flaws openly. 

[Cory]

From what I've seen on Twitter, WxBell isn't interested in applying a correction (or acknowledging a problem). 

[JoMo]

From what I've seen on Twitter, WxBell isn't interested in applying a correction (or acknowledging a problem). 

 

They've already said there is a problem multiple times. However, it comes from the Euro not defining precip types. 

[Cory]

They've already said there is a problem multiple times. However, it comes from the Euro not defining precip types. 

 

Ah, ok. This was an older conversation I found on Twitter. It was November 2013, I was thinking it was this year. 

[InstantWeatherMaps]

I imagine there's multiple reasons why map distributors have the Euro snow maps the way they do:

1) To be consistent about how snow is handled (in post-processing) across all the models they show.

2) The additional computations in post-processing = slower map output, hurting the companies that compete with others in being the fastest map producers.

3) They don't think that there is enough of a payoff to put the time and effort into creating additional post-processing procedures.

That's just it. The Euro has a "Snowfall" parameter, and it's (both computationally and monetarily -- ECMWF charges by the parameter up to a very high maximum) more expensive to grab a lot of parameters you "don't need". It's not that they are trying to be consistent at all; in fact they can't be consistent (if they're using anything but a straight 10:1 for the GFS) without paying a large amount of money, and most people will presume that the Snowfall parameter is better than a straight 10:1 based off the QPF and snow flag (it turns out those two are probably identical; I don't have access to the ECMWF GRIB files beyond the free ones so I can't say for sure). Also my GFS snowfall maps are out within 1-2 seconds of the model data availability... granted, for that second or two I'm using up three entire processor cores producing the maps, but still snowfall maps aren't a very big deal in terms of speed if you optimize things right (without optimizations I will admit it took almost a whole minute to generate the 192hr snowfall map). TL;DR: Money is the primary reason they don't use Kuchera; the complication of optimizing the code is a secondary concern.

 

The best thing that can be done with model output snowfall graphics is to destroy them.  Just eliminate them.  I really don't see the point to them except to be tossed around and used irresponsibility.  I suppose you can make an argument that it's just a tool for forecasters as perhaps a reference or something but IMO they just don't do any good.  For anyone who forecasts, there are numerous data sources and numerous outputs available that a forecaster can use to come up with a very sensible forecast using his/her's abilities and talents.

I respectfully disagree. If a human can come up with a better snowfall map based off a single model output than a computer can, then what is needed is a better algorithm, not a total eschewing of post-processing altogether.

 

 

 

Oh, and by the way, my thoughts on WxBell snow maps (copied and pasted from my post on a local weather forum): I have taken a serious look at WeatherBell's snow maps recently, and I don't believe most of them inflate totals necessarily. The snowfall maps tend to overdo snowfall in the south and underdo it in the north, and this is entirely due to their usage of a 10:1 ratio instead of a dynamic ratio like our maps use. Thus, the maps are suboptimal but not necessarily bad by any means, but they do take additional human input to read correctly than our snowfall maps do. This is true of all of their maps with the word Snowfall in their name. (Edit: the ECMWF snowfall maps are based off a flawed algorithm that says that all wintry precipitation is 10:1-ratio snow, so the amounts are very overdone in wintry mix situations)

Their snow depth maps are OK, with the exception of the ECMWF snow depth maps, which suffer from the same hyperinflation problem as TwisterData's maps. All of their maps maps with the words Snow Depth in their name which do not contain the word 10:1 are perfectly fine; the ones that do contain the word 10:1 (the ECMWF snow depth maps) are total bunk, as a 6:1 ratio is more realistic for snow depth (and frankly a ratio shouldn't even need to be used given that Snow Depth and Snow Density parameters exist in the ECMWF inventory... this is at best an attempt to save a couple of thousand dollars per year and at worst an attempt to provide inflated snow amounts for posting on Twitter).

 

As far as other sites (also copypasted from my own post on another forum with some modifications, note this was a direct reply to a question about my site): AmericanWx Model Center is fairly accurate (although they are based off a flat 10:1 ratio, so the same caveats apply as with WeatherBell non-Euro snowfall maps), and TwisterData snow maps are definitely incorrect (10:1 ratio snow depth? Seriously? Especially when the model itself has a pre-corrected snow depth output...). Accuweather Pro's snow depth maps suffer from the same problem as TwisterData's; their snowfall (snow accumulation) maps claim to be a typical 10:1 ratio but appear to have some sort of compaction and/or melting algorithm in them... because of this the snowfall maps are underdone compared to most 10:1 maps (except, again, the ECMWF, where the poorly done precip type algorithm really shows). Both Earl Barker's site and my own use the Kuchera method; his also has 10:1 snowfall for comparison, which has aided me a lot in comparing the different sites. The small differences between his Kuchera maps and mine are due to a slight improvement I made in my algorithm which keeps large rain/snow dividing line areas from being shown as all snow or all rain (typically the former... usually my improvements result in a small drop in the output value). My site has always used, and will always use, the direct model output for snow depth and the Kuchera atmospheric temperature snow ratio calculation algorithm for snowfall. We do not use, have never used, and will never use 32F/0C as a magic number for any snow calculation (Euro snowfall parameter and snow flag, I am looking at you). That leaves StormVista, EuroWX, and Tropical Tidbits. I can't comment on the first two since I don't have subscriptions (and I have nothing to compare EuroWX's maps to other than the obviously flawed pseudo-10:1 method used by WeatherBell and others); I can't comment on Tropical Tidbits because the site is down.

[UNCCmetgrad]

Cory,

 My provider, Earthsat, also has something screwy. They have ~4-9" of snow ~12/4 from northern OK to E KS in an area where the 850's are well above 0C...like +4 to +6 C. However, the two meter temp.'s are near or just below 32. So, this must be ZR and perhaps some IP.  As I was told by Earthsat, the Euro snow maps treat ZR and IP liquid equivalent like SN. This is not just a WxBell problem by any means and it has been going on since at least last winter.

Just to throw my two cents in here.  I first signed up for weatherbell just before they really expanded their high res EURO products. On the old EURO snowfall accumulation product I think there was a dislaimer at the bottom that read something like snowfall accumulation at 10:1 ratio if surface temperatures at 32 or below in last 6 hours. Obviously with this you would get snow with 850's warmer than 0C as well as ice showing as snow accumulations. When they added all of the high res Euro products that disclaimer went away but I think they still use the same algorythm. Sounds like EarthSat uses the same as WxBell.

[Ellinwood]

Sounds like EarthSat uses the same as WxBell.

 

Not quite... back when I was working there and could compare the maps, WxBell had consistently higher totals on the snow maps compared to MDA/EarthSat.