I stumbled upon a discrepancy in Honeybees annual irradiance simulation. I compared the results of the old workflow (Honeybee Annual Daylight Simulation from VER 0.0.64) with the new workflow (HB Annual Irradiance from VER 1.3.0). I made the same assumptions for both workflows, simulating the radiation on a surface (1 m²) parallel to the ground. I might have made some mistakes in setting up the new workflow as I am not as fimiliar with it as with the old one.
But assuming that the workflow is correct, I got the following results: Annual total radiation simulated with VER 0.0.64 is fitting quite well to the actual total radiation defined in the weather data. VER 1.3.0 however, creates significantly different and higher radiation values for the same setup.
Has anyone of you already encountered that issue?
Unfortunately I can not add attachements to this post, as I am a new user, but maybe someone is able to recreate the results or can enable me for uploading.
There was a bug in the HB Annual Irradiance component that I just fixed this week. So that’s why the radiation values out of that component are so high. You can get the fix on your end with the LB Versioner. Or you could just use the Cumulative Radiation component until the LBT 1.4 release. The Cumulative Radiation is suitable when you only need cumulative radiation over time and will be faster than the Annual Irradiance recipe.
thanks for your response. I chose the annual recipe and set the output units within the DSParameters to W/m². Is this also possible besides the grid-based approach?
But great to hear that the bug was fixed already. I will go the way with the LB Versioner.
I did load the latest Version of LB and synced the HB Annual Irradiance component in my file.
Unfortunately, the total radiation on a horizontal surface calculated by this component is still not fitting with the actual EPW weather data. In sum, it is now lower and the hourly results are diverging from the EPW data in the course of a day quite a lot.
Ah, thank for testing it further @Koba . You’re right that there was one more bug in the recipe, which is that I forgot to generate the sky matrices for broadband solar irradiance instead of illuminance. I just pushed a fix for this:
… and you should now be able to get it with the LB Versioner.
I also verified that the new recipe produces irradiance values that are within 1% of the EPW values:
Also, I had forgotten that DAYSIM has the ability to request irradiance values instead of the default illuminance. You are right that the “HB Annual Irradiance” recipe is meant to be equivalent to running DAYSIM (aka. the Legacy Annual Daylight recipe) with irradiance values requested. However, now that all of the bugs seems to be fixed, the “HB Annual Irradiance” recipe in the LBT plugin should be a bit more accurate than DAYSIM in the way that it models the direct sun contribution. We’re using an enhanced 2-Phase recipe in the “HB Annual Irradiance” component that is closer to the results you would find from point-in-time simulations:
everything is working perfectly now. Thanks for solving the issue and for the little insight into the new approach of the “HB Annual Irradiance” component.
