Convert solar radiation to the main orientations/inclinations

[saroele]

The weather data we get from darksky.io now contains solar radiation. We get the following variables: 'DiffuseHorizontalIrradiance', 'DirectNormalIrradiance', 'ExtraTerrestrialRadiation', 'GlobalHorizontalIrradiance', 'SolarAltitude', 'SolarAzimuth'.

We need a function to compute the solar irradiation on the main (building) surfaces: vertical north, east, south and west and inclined surfaces at various inclinations between east and west.

I think what we need is a method in the forecastwrapper.Weather class that takes a list of tuples (azimuth, inclination) and adds a column in the hours and days DataFrames for each tuple. This gives us flexibility to define the azimuth/inclination pairs as we see fit (eg for analysis of PV we need different combinations than for analysis of gas consumption).

I will not be efficient at implementing this. @JrtPec knows how to implement this in the forecastwrapper but maybe he needs a little help from @kdebrab or @rubenbaetens for the formulas and a quality check? Thanks folks!!

[JrtPec]

I propose a similar approach as with the degree days, where you can ask the days function for different base temperatures: You could ask for pairs of a specific orientation and tilt, and it will yield the daily irradiation for that pair. Eg. weather.days(irradiances=[(orient=90, tilt=90), (orient=180, tilt=90)]), where irradiances is a list of namedtuples.

As it happens, I have already made the formula to calculate the irradiance for a given orientation and tilt, from when I made the theoretical solar model:

irradiance = DNI * (cos(altitude) * sin(tilt) * cos(orient-azimuth) + sin(altitude) * cos(tilt)) + DHI

Edit: I will try to break the formula up into its components. Here is a graphical breakdown: from http://www.pveducation.org/pvcdrom/properties-sunlight/solar-radiation-tilted-surface

[JrtPec]

@saroele I'm writing something that calculates the Global Irradiance for a tilted surface, works basically by transforming the Direct Irradiance to the given surface + adding the diffuse component.

For PV-modelling you would always need to add this diffuse component. I don't know if you also want just the direct component for heat profiling?

[saroele]

I would say that the total radiation recieved by the tilted surface is what we need at this moment, so the sum of direct and diffuse. If we need something else later on, we can refine the method and results.

Is it possible to also add it to the hourly weather dataframe?

[JrtPec]

Ok. I'm start by calculating everything per hour, next aggregating it per day, so it will be available in both frames.

I just found a problem though: if you look at the azimuth values on an hourly basis, it seems like Dark Sky has the sun coming up in the North and setting in the South... Luckily I have contact details of their development team so I'll be filing a bug report.

[saroele]

It's not a matter of conventions?

[JrtPec]

Of course it is. I did some tests and noticed that the azimuth is consistently off by 90 degrees: a value of 0 corresponds with East.

In the mail I received from Dark Sky they wrote:

azimuth is the direction of the sun in degrees, measured from true north and proceeding clockwise (as with the other bearing-type properties in the API)

So I think this is a bug on their end. I will notify them of this and ask if this is intentional behaviour.

As for us: I believe a convention of 0=North is way clearer, so I will implement a correction until I hear from Dark Sky.

Edit: This is from the API docs on wind bearing:

The direction that the wind is coming from in degrees, with true north at 0° and progressing clockwise. (If windSpeed is zero, then this value will not be defined.)

[rubenbaetens]

Fyi, i think internationally they try to converge towards the convention that 0°C points towards Solar noon and thus towards the equator, i.e. pointing South for locations in the Northern hemisphere and pointing North in the Southern hemisphere.

[JrtPec]

I got a response from Dark Sky:

I can confirm what you're seeing, and apologize for the error: azimuth is indeed measured from the east axis, while wind bearing is measured from the north axis.

This will not be the case when this data becomes live (additionally, the name of this property would be changed), but for the time being you are handling it correctly.

First: I have already implemented a workaround in our code, so the azimuth is fixed and measured from the north.

I'll ask them to notify me when they go live, so I can remove the workaround. Everybody will also have to clear all cached files when that happens.