At the same time, more and more people live in cities, where the access to local renewable energy sources –wind and solar- is limited. If so, it will difficult to users to catch what to do (input manually the Longitude and TZ).By the end of 2020, all EU member states need to ensure that all newly constructed buildings consume ‘nearly zero’ energy and that their energy needs are produced locally as much as possible and with renewable sources a concept called nearly Zero Energy Buildings (ZEB). But this component is not included in the released version (v0.0.35). The DecomposeLocationData component has the 3 outputs and then the correction works. It is a bit of unconvenient to look for these, and then sometimes user may “forget” or miss to input one/both of them into the Sunpath component (as seems to be the case with Stefania … and me ). For Local time you need both Longitude and TimeZone. What may lead to the confusion is that the ImportEPW component has only Latitude output. I would only add an explanation in the Help of the relevant components about the meaning of using Solar vs Local. But sometimes user may want to use each of them(SunlightHours vs Radiation, for instance). It will be quite confusing.Īgree that the conversion Local Solar may be confusing.
The altitude is quite close.įirst, what NOT to do: 2 sunpaths. I see that now the azimuth difference is a bit more than 1 degree (1.1 to 1.3). Hope this helps to make this (important) point clear. I’m attaching my checking file, using Tel Aviv EPW at 10 am, for your convenience i concentrated the numbers in excel. As you can see the differences can be very significant. People (me) always thing about Time as the one you see in your clock (civil) and not the one according to sun position. I don’t know if LB calculations take into account the Equation of Time, or earth declination, but i think the formula should be revised.Īlso the input time is a matter of discussion. I’ve found that the input time in LB is, probably, the Solar Time and the others is the local time (or civil time … your clock).Īfter i use the Solartime as input for receiving the azimuth/altitude the results are more consistent with those of LB (for this specific example, instead of giving 10 i gave 9:38). Since my calculations are consistent with those of the websites and Diva’s, and even with those of Ecotect (yes, i have the numbers) i started to thing what could be the problem (it is not daylight savings!!). The differences with LB remain about the same. Then i calculated by myself the numbers and even consulted a couple of websites ( NOAA & ESRL and pveducation). There are differences, even meaningful ones (5-6 degrees in the azimuth, 2-3 degrees for altitude). Started comparing the solar vectors LB calculates against DIVA’s, for Tel Aviv EPW, 10 am. So i decided to check this more thoroughly.
I was curious about the original question and Mostapha’s reply. I’ve found some issues that maybe a discussion is more appropriate. I’ll continue the tread here as a discussion and not as a comment.
0 kommentar(er)
