HB+, legacy and DAYSIM results

Hi @sarith @mostapha,

Just found there is a problem in HB+'s climate based sky, there is one hour off than legacy version and the sunpath.
Please see attached screenshot.
GH file also uploaded for your test.

hb Test.gh (192.0 KB)


Thanks @MingboPeng, Thanks. We probably should open an issue on GitHub for this. Did you check the results for sunrise/sunset hours? Not sure if this is because of the difference in the sky or just a mistake in loading the results.

Yes, because I didn’t check the code at all, not sure it is meant to be or a bug. I will dig a little bit more.

@sarith and I talked about this a little bit more and the results from Honeybee[+] is actually the correct one. Here are a couple of notes:

  1. Both Daysim and Honeybee[+] are using the hour between the two hours for the simulation. If you check the wea file you’ll see that the hours are 8:30, 9:30 and so on. For the comparison you need to set the sun-path time to 9:30 to get the correct direction.

  2. Daysim uses 61-65 sun positions for direct calculation, however Honeybee[+] uses the exact position of the sun for the direct calculation. See this paper for more information.


Just to add to the clarification by @mostapha , if any one is interested in checking, the solar discs used by Daysim can be found inside the tmp folder. For this example, the suns used in the direct simulation by Daysim are visualized below:


@mostapha @sarith Thanks. My mistake. I was testing the point in time, I meant Radiance, not Daysim.
It looks like there is a bug in HB+ WEA converting process. Please see below, the radiation values are different, but locations are the same.


But I also tested the same hour from the annual simulation.

Yes, HB+ is more accurate.


I uploaded gh file here just in case any of you want to double check. I will try to dig into a little bit more as well.

hb Test.gh (612.9 KB)

Here is an update for the DC with annual sky matrix, and getting hourly data:

@mostapha @sarith
The results are clearly not correct here.
It is reading 10AM data, and it is actually 1PM data

I manually read all the ill files:

Sun.scene.default.ill at 10AM (Actual 1PM)

Added to GitHub as an issue. I think I’m planning to do too much for this weekend but hopefully this will be one of them to check. :slight_smile:

@MingboPeng, The point-in-time difference was because of what is discussed in this discussion and is now fixed:

I will check the annual analysis next and report back shortly.

I fixed the division by zero error and I can recreate the mismatch when I load the hourly results. I assume it happens during loading the results and not the calculation itself. I say that since the calculation by generating the sky for a single hour works as expected.

@mostapha thanks for fixing this. I wish I could have helped on this.

@MingboPeng, I can recreate this error (the difference between sun and direct files). Sunmatrix is most likely the source of the issue as you have pointed out. Let me investigate more and see why this is only happening in case of several hours. It’s most likely an issue in creating the sunmatrix itself. The results are not in the right order and the error pattern is not consistent.

Ok. It’s finally under control. :wink:

The issue was naming of suns in sunmatrix. It was an easy fix but very hard to find. I have one more bug to fix for sDA calculation and after that I will update the installation files.

Here are all the cases next to each other. It’s a good example file to show how honeybee[+] approach is both faster and more accurate than Daysim.

Here is the file: test_honeybee_vs_honeybee_plus.gh (633.9 KB)

Thank you @MingboPeng for finding this issue and reporting it!