Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

angle convention for sun angles #22

Open
Linwal opened this issue Jul 7, 2017 · 3 comments
Open

angle convention for sun angles #22

Linwal opened this issue Jul 7, 2017 · 3 comments

Comments

@Linwal
Copy link
Contributor

Linwal commented Jul 7, 2017

Within the radiation.py file the sun position is calculated with the function calc_sun_position(..)

When comparing calculated values to values from http://www.suncalc.org you will realise that the values do not match. This is not due to a wrong code but to a different convention of the azimuth angle. The convention which the code of radiation.py is using sets 0 in south direction, positive values towards east and negative values towards west which is the traditional approach.

"However, despite tradition, the most commonly accepted convention for analyzing solar irradiation, e.g. for solar energy applications, is clockwise from due north, so east is 90°, south is 180° and west is 270°. " (https://en.wikipedia.org/wiki/Solar_azimuth_angle)

Also Ladybug and Honeybee use the "North convention".

I propose to inform about that in the function's description. It is then easy to transform the results from one convention to the other.

A second important issue is, that the HOY input must be in UTC time and not in local time. Going through the code this becomes clear. It could be specified already in the description of the input parameters for more clarity.

@pjayathissa
Copy link
Collaborator

@Linwal
Re-adressing this issue that got pushed to the back-burner. Has it also been resolved with pull request #41

@pjayathissa
Copy link
Collaborator

@Linwal just chasing up if this is still an issue or whether you solved it in your PR #41

@Linwal
Copy link
Contributor Author

Linwal commented Aug 10, 2020

@pjayathissa
In my opinion it is still an issue that the time used in the solar angle calculation is UTC and not local time (At least that is how I read the code). I think a "simple" conversion could be added that classifies the longitude of the weatherfile coordinates into a "typical timezone" according to 15° steps per hour. (Of course then it still needs to be clear that this is not local time everywhere). I also still think that the north=0 convention is more intuitive but ultimately, when this is clear for the window definition, it doesn' matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants