Hi everyone,
I am currently experimenting a bit with the new recipes just added in the update of LBT 1.2.0.
What I am doing is a simple simulation comparing the results between the new RAD recipe and the one in Honeybee+ for a south façade with shading obstacles in front of it. I was expecting to have very similar output when setting the same HOY (6326 HOY, corresponding to 2 p.m. of the 21st of September) and radiance parameters, however, both the average value for irradiation on the façade and the visual output from the colored mesh are different.
From the visual output, I suspected that this could have been related to a “shift” in how the sun position and radiation are calculated in the two recipes. So, I tried to rotate the north for the LBT 1.2.0 simulation of 7.5 degrees to simulate a time shift of 30 minutes and, in this way, I got similar results between LBT and HB+.
It looks like the two recipe consider different sun position (the one at full hour in one case, and the one in between two hour for the other case) for the two recipe!
Can someone please explain what is going on here? Is this a bug of the new component or is it a new standard introduced with the last release?
And, if this is was introduced on purpose, how is it possible to compare old results/studies done with HB+ with the new LBT?
I also attached the script I created if you want to have a better look at it.
Thank you in advance for the answer and congratulations to the developers and the community for the great job with the new LBT!
Best, Matteo
Hi @Matteo,
Can’t check the part of HB+ since i don’t have it installed. But the LBT part is indeedd related to the half an hour difference between the EPW and the WEA times.
Checking with the ViewFromSun component you can see that the resulting radiation WITHOUT the half an hour looks like the HB+ and with it is the LBT results.
This explains the differences.
-A.
Hi @AbrahamYezioro and thanks for the interest and the explanation,
So you say that there is half-hour difference between the times in in EPW and in the WEA but than why the difference in my case?
I still don’t fully get it. After all, both the recipes ask for WEA as input, in LBT it goes straight into Annual Radiation component, while in HB+ in passes first through the Sky Matrix component.
You are absolutely right that there’s a difference of exactly 30 minutes and, a least for the LBT plugin, the fact that the sun position falls on the half-hour is intentional (eg. 0:30, 1:30, 2:30, etc.).
The reason why the LBT plugin uses a sun position on the half hour goes back to a quirk of the EPW file format - that the EPW starts counting from 1:00 as the first hour of the year (not midnight as you would expect). However, the radiation value at 1:00 (and for all following hours) is meant to be a cumulative radiation value over the whole previous hour. So, if we had to assume a sun position that best aligns with the EPW radiation values, it would be that of the previous half hour (0:30 for the first hour of the EPW).
So I feel pretty confident saying that the LBT method is correct or it’s at least more correct than it would be if we used solar positions on the hour.
I didn’t really have much of a hand in putting together Honeybee[+]. @mostapha and @sarith did most of the work on HB[+] and maybe they had a reason for using sun positions on the hour instead of the half hour. It’s also possible that Honeybee[+] is just older and we all didn’t have as much of an understanding of this quirk of the EPW file at the time. I didn’t really understand it until I realized that it permeates the whole EnergyPlus application (implementing EnergyPlus schedules was exhausting because of this). It’s probably a major reason why this E+ GitHub issue has so many .
In any event, hopefully the 30-minute difference in sun positions over the whole year doesn’t make a huge difference in cumulative radiation, even though I know it looks big on an hour-by-hour basis.
I’m adding some clarification here to make sure Daysim gets credit for the sun adjustment and also some clarification about the difference in HB[+]. They are all documented on the web but it looks like they have not been clearly communicated.
We didn’t come up with the idea of half and hour adjustment. It was well documented in Daysim and that’s how epw2wea which is a Daysim command works. The main reason behind the change in Daysim is for supporting shorter timesteps. For hourly timesteps the difference is negligible. You can read Christoph’s explanation here:
Thanks Thomas. Just to add to this. The Daysim weather file uses the middle of the file interval during which the solar radiation data was collected. This means for the first hour of the year 0.30AM and so forward. The reason for this choice is that shorter time steps can be treated using the same file format. Daysim actually checks whether sunrise or sunset take place during a particular time interval and slightly adjusts the time to the middle of the interval of the time step when the sun is above the horizon. E.g. if the sun rises at 6.30AM Daysim uses the middle of the above horizon interval, 6.45AM, to determine the position of the sun during that time stamp. If Daysim used 6.30AM instead, the Perez sky model would yield an error.
Christoph
The sun position in HB[+] is a known bug and is documented here:
honeybee-radiance which is the core library that is used for the LBT plugins uses the Radiance implementation for sunpath which uses gendaymtx under the hood - HB[+] uses a Python implementation of 'gendaylit` and Ladybug Tools’s sunpath which is actually more accurate. There means there will be a slight difference both in sun position and irradiance values.
Blue-ish colors are Rediance and red one’s are Ladybug. This is happening because Radiance’s sun position calculation uses an integer Julian date. But as I said the differences are very small.
If you are interested here is the comparison between gendaylit -O1 and gendaymtx -O1 values. See the last column where they are pretty much in agreement.
.