free climate dataset for any location in north Europe - now also worldwide

[LukasL]

I'm working on a project making gridded meteorological data from open data sources available for hygrothermal and energy simulation communities. You can access the data from here:

https://shinyweatherdata.com

Source of data are the Swedish Meteorological and Hydrological Institute (SMHI) mesoscale analysis systems. These systems will be updated (probably before end of 2016) and will get improved solar radiation data with a much higher horizontal resolution (2.5 km instead of the present 11 km)

I hope to update the web tool with new datasets as they becomes available. There's are many interesting projects going on like the UERRA re-analysis which I believe will be excellent source for gridded climate datasets for hygrothermal simulations, as these re-analysis systems focus on precipitation data and have better quality control than operational now-casting data.

Let me know if you have any issues or comments about the tool or datasets.

Lukas Lundström
PhD student at Mälardalen University, Sweden

[Christian Bludau]

Hey Lukas,

great job. I pin you up for a while.

I noticed, that the height of the picked location and more important the time zone is not right in the wac file.
The time zone is quite important as this is used for calculating the position of the sun.

Greetings,
Christian

[Christian Bludau]

Hi Lukas,

I have another note for your wac-file. We have defined two describing files for teh location in the header. The station name and the description.
Maybe it would be possible to place the name of the picked city in the "Station Name" line and the information about the data source in the "description" line.
See header below.

Regards, Christian



WUFI®_WAC_02
10 Line Offset to 'Number of Data Columns'
Station Name
Description
15.79 Longitude [°]; East is positive
50.22 Latitude [°]; North is positive
230 HeightAMSL [m]
1.0 Time Zone [h from UTC]; East is positive
1 Time Step [h]
8760 Number of DataLines
10 Number of DataColumns

[LukasL]

Thank you Christian

I've the air pressure as MSL (mean sea level). But as I don't (yet) have the height information I've set the MSL pressure as station pressure (PSTA in Wufi) and height to 1 m, as suggested by Tobias Schöner from the WUFI Support Team.

I believe this is fine for Wufi where air pressure shouldn't be so important. But for energy simulation, involving natural ventilation for example, air pressure is an important parameter. I'll update with height information in near future.

The time is set as UTC. It seems to be working right, judging form the radiation graph that you get in Wufi. I assume Wufi uses the longitude together with timezone offset and some solar time calculation to get the sun's position right.

One problem is that Wufi apparently don't care about the time stamp information in the TIME column, it seems like it just assumes the first row to be first of January at 1 o'clock. But the SMHI datasets starts from 0 o'clock (or 24 o'clock of the 31 December if you prefer). I solved that by deleting the first record which gives a dataset of 8759 rows. This triggers a warning in Wufi but I don't know if it's real problem (I could simply duplicate the last record if it's important with 8760 rows).

Regards,
Lukas Lundström

[LukasL]

Hi Christian,

Yes I'll fix the header information according to your suggestion in the next update.

Regards,
Lukas

[Thomas]

One problem is that Wufi apparently don't care about the time stamp information in the TIME column, it seems like it just assumes the first row to be first of January at 1 o'clock. But the SMHI datasets starts from 0 o'clock (or 24 o'clock of the 31 December if you prefer). I solved that by deleting the first record which gives a dataset of 8759 rows. This triggers a warning in Wufi but I don't know if it's real problem (I could simply duplicate the last record if it's important with 8760 rows).

Hi LukasL,

thanks for your weather data. Yes, WUFI currently ignores the TIME column. At present, that column is only for the convenience of the user, and WUFI always assumes that the first line of the weather data contains the data for the first hour of the year.

Please note that according to the time stamp convention used by WUFI, the time stamp always refers to the time when the data were saved by the measurement system. That is, if data are measured between 14 o'clock and 15 o'clock, and the resulting hourly mean values are saved at 15 o'clock, the corresponding time stamp is "15h".
According to the specification of the WAC format, the first line of the data contains the data of the first hour of the year. This is the data measured between 0h and 1h, and the time stamp for this data line is thus "1h". A time stamp "0h" for the first data in your data source would indicate data for the last hour of the previous year (saved at midnight), or it may be due to a different time stamp convention. If there is doubt which of both is the case for the source dataset you used, you might wish to check this.

If the data source actually starts with the last hour of the previous year, these data should be removed. Another data line should then be added to the end of the file (maybe by duplicating the last existing line) to complete the line count of 8760. Often multi-year simulations are done with only a file for a single year which is then read again from the start when the end of the file is reached. If the file is too short by one hour, WUFI has to jump back to the beginning one hour too early and there will be an accumulating discrepancy between WUFI's calendar date count and the weather data actually used for that date.

You can use whichever time zone you wish for the time stamps, but the time zone indicator has to be consistent with your choice (in fact, it is there to tell WUFI what your choice was). Depending on your choice, a given hour may be the last hour of the previous year (in one time zone), or the first hour of the current year (in another time zone), so the choice of a time zone also affects which data are supposed to be the first data of the year.
I sometimes get data sets which have time stamps in "UTC" but include the last hour of the previous "UTC" year. I prefer the time stamps to be in "CET", so I'm renumbering the time stamps, and the last hour of the previous "UTC" year happens to be the first hour of the current "CET" year, so the data source gave me precisely the data I wanted.

Regards,
Thomas

[Christian Bludau]

I also want to add something:
Please do NOT delete one our. WUFI calculations are usually performed over many years, circulating the climate file. As there can be no day without climate, the calculation jumps from the end of the climate file to the beginning. If you use climate files with 8759 instead of 8760 hours, you get a yearly time shift of about one hour.

Please also note:
the wac-files should not contain the 29th of February. Otherwise you will get a yearly time shift of a full day.
Christian

[LukasL]

Hi Thomas and Christian

Data from mesoscale modelling systems have instantaneous values for the full hour (except rain that is an accumulated value). For now I'll just delete the fist row and duplicate last one (in the future I'll include the first row from the next years record instead).

Another possibility would be to interpolate backward half an hour (which I do with the solar data). But that would introduce smoothing which I believe would do more harm than the benefits from shifting to correct timestamp would have. Actually many observed datasets are instantaneous as well (for airports data the timestamp e.g. at 13:00 are usually instantaneous values recorded at 12:50, or a average of 12:20 and 12:50)

I was just about to ask about the leap years, I'll follow Christians advice and delete the 29th of February.

Regards,
Lukas Lundström

[LukasL]

I’m an energy modeller myself with no practical experience from hygrothermal simulations, so I would appreciate input about what your needs are. I think that in the hygrothermal field climate data representing severe conditions of different kinds are of more interest than typical/normal years? For example Energyplus has an algorithm that identifies extreme weather periods, in weeks and from an energy consumption point of view. Are there any know methods/tools that would do a similar thing for hygrothermal simulation purposes?

How about a web service that would by statistical methods pick years that are particularly severe (cold, warm, humid etc) for a freely selectable location?

Regards,
Lukas Lundström

[LukasL]

The Shiny weather data tool has been updated. There's now a option to use CAMS radiation service as source of solar data. CAMS is the better choice if your location is outside of Sweden and south of roughly 60°, which probably includes most of you in this forum .

Regards,
Lukas Lundström

[LukasL]

The https://rokka.shinyapps.io/shinyweatherdata has been updated with new data from ERA5. Which is a reanalysis climate dataset from Copernicus/ECMWF, with global coverage and data from 1980 until recent time.

I've got a few inquires about exporting directly into the WUFI/WAC format, as WUFI currently doesn't support importing rain data from the EPW format. There is an experimental site at https://rokka.shinyapps.io/shinyweatherdata_testing where this feature is currently available. I actually don't have an active WUFI license my self, so not sure it works. Not sure that that I'll support the WAC format in the future as it is a bit of a hassle validating it when I update things. I would much rather spend my limited time (this is a non-paid side project) on making more data source available to you E.g. I like to add the CERRA dataset which provides high resolution data for Europe (supposed to be more accurate regarding rain data).

Best regards,
Lukas Lundström
PhD in energy systems