I’ve seen that LBT1.2 has just received a brand new function for calculation of Direct Sun Hours using radiance, that’s exciting! I was relying on Ladybug Legacy Sunlight Hours Analysis to do that, which was rather difficult to use for larger models.
When running a test simulation using both engines, I realized that the results are completely different. The radiance-based calculation reports about half of the direct sun hours of the ladybug component. It also appears to me that the orientation matters far less in the radiance-based than in the LB-Legacy. See two examples below, for south and easy orientation. The highest number is the LB Legacy, the lowest the new component from LBT1.2.
Hi @pmcmm, thank you for checking the results and reporting this? Can you share your model with us to be able to re-create this issue. I did some checks and the results were in close agreements but there is a chance that we have missed some additional checks.
Hi Mostapha, here is an example file. The result discrepancy is more accentuated in the east/west direction. Also, if I connect a profile to the hoys in the weather file, I get no results. I highlighted this piece of code in green in the script. This one might be my fault, gotta investigate further.
The file is too big to upload here, please find it in this link:
[broken link, see below]
I’m sorry, @pmcmm , but the file that you uploaded has just too much extra stuff in it that is not related to the question you are asking. You are also mixing the legacy and the LBT plugin, which is not really the best practice when there is already a LBT ladybug component for direct sun hours that you can compare with LBT honeybee.
The one problem that I could see is that you have an analysis period selecting sun vectors for your legacy ladybug analysis but your LBT honeybee analysis is completely annual. There are probably more issues but it’s just tough to tell given that the file doesn’t have the minimum that’s needed to recreate the issue.
Hi Chris, I’m sorry to waste your time. I had cleaned up the file before sending, however I forgot to pass the weather file to a web address. It’s normal that you couldn’t run the script…
I’ve updated the file, can you try again? I’m now comparing the three methods of calculation, Legacy, LBT1.2 and radiance sun hours. The Legacy and LBT1.2 have small differences of 2%, but radiance results are consistently > 50% lower. It seems rather strange that, for east/west orientations, the sun is only detected near he window.
As for the analysis period, I had run some tests with that, that is not the problem. For simplification, the script now runs annual simulation for the three scenarios.
@pmcmm ,
Your file is still large and there are some odd things about it that it would take too long to work through but, when I rebuilt the file for myself with your geometry, the results are somewhat close:
Still, you are correct that the Direct Sun recipe is a bit on the low side. @mostapha , do you have any idea what could be happening in the direct sun recipe here?
It looks like some hours are randomly getting dropped from the Radiance direct sun calculation (on the top). However, on closer inspection of the EPW, these hours are not random. Rather, they are hours where there is 0 direct sun:
So it looks like the “Direct Sun Hours” recipe is actually performing a different type of calculation from the Ladybug “Direct Sun Hours” component. That is, it’s a calculation that accounts for BOTH solar position at each hour and whether there is any direct irradiance.
Is the the intended behavior of the recipe, @mostapha ?
If so, we should probably make a clearer note of it in the recipe description. Or perhaps we should change the recipe name to be something different than the Ladybug component.
It’s not the intended behavior but I’m not sure what’s the best way to resolve it.
There are two ways that I can think of. One is to re-write the wea file to make sure all the hours have a high value (800, 800) or we should create a new sunpath file where all the values are set to 1000000 or something like that and use that one for the study. That’s how it was written in HB[+]. The first one sounds easier to implement. It’s basically an extra command that reads the input wea file and sets all the values to a constant non-zero value and we can use the new wea file for the rest of the study.
If the intention is to produce the exact result as the Ladybug component, maybe we should also change the datetimes of the Wea to align with the hour instead of the half-hour. We should also probably remove this “direct radiation” output that you have on the recipe under the hood (not currently exposed on the component):
Since this direct radiation doesn’t have any meaning when all of the Wea values are the same.
Let me know if you agree with all, none or some of these ideas.
Yes. It all makes sense except that I’m not sure about the half an hour change because that’s something that the user can do in the input wea file if intended. We are just using the input wea file as is. This will become more important for wea files with smaller timesteps and that’s why I suggest to leave the datetimes as is.
Thanks @mostapha . I can start putting together some methods/arguments in ladybug-core that can make constant-value Weas for this purpose. What you said about users being able to edit the input Wea is not 100% correct. We hard-coded the fact that Weas with a timestep of 1 should fall on the half-hour into ladybug core:
Granted, the half-hour is what you want to be using whenever you’re using a Wea that’s aligned with EPW data and the only reason why we are considering foregoing the half-hour here is because a constant-value wea isn’t aligned to EPW data. But maybe we still want the default sun position for this recipe to be on the half-hour to align with the other Radiance recipes.
Just knowing that alignment to the hour might be be a use-case for certain studies like this, I think I will add a property to the Wea object that allows users to override this default behavior at a timestep of 1. I won’t expose it on any Grasshopper component but I’ll do this as I add the core library methods to convert Weas to constant value.
Let me know if you think it’s more important that that this “Direct Sun Hours” recipe align with the other Radiance recipes or align with typical Ladybug Sunpath studies and I’ll implement it accordingly on the recipe.
My vote is to align it with other Radiance recipes by default. An option to change the sun position can be helpful in rare cases.
What will happen if someone imports an hourly wea file which already has hours adjusted? I assume we push that back to so we don’t double count for the adjustment. Right?
No, we never double-adjust the hours.
The user has the option of specifying the timestep when they import a Wea file:
If the timestep is 1, we enforce the default behavior and assume everything is on the half-hour of whatever hour is specified in the Wea. If someone specifies any other timestep, we use the exact datetimes in the Wea (even if the Wea has no values for a given timestep and is thereby represented thorough a Discontinuous Data Collection).
Radiance takes into account climate conditions, so it makes sense that this recipe is no different. On the other hand, most norms requiring the calculation of direct sun hours require the use of a completely sunny sky for analysis. So this new Radiance-based direct sun hours could have little use in practice, and it would not supersede the LB Direct Sun Hours, which was your goal according to what’s written in the components.
I see you are deciding to follow the traditional radiance approach. What about having a boolean in the component, in which one could switch to set the sky to fully sunny - all sun hours to 100.000 before running? Default approach, radiance-like - alternative approach, LB Direct Sun-like?
I was playing around with your solutions, namely with the radiance-based recipe and modifying the direct radiance in the weather file. The results got closer to each other indeed, but some things popped up in my analysis:
radiance-based only returns results for 4.393 hours whereas LB returns 4.438. These hours are happening at the beginning and end of the day. This is also related to the 30 min difference, as they are added in the beginning and removed at the end of the day.
If there is such a difference in sun hours, then radiance must be basing itself on the weather file. However that is not the case, the weather file you provided had 4.604 of global horizontal radiation > 0. So what could be the explanation for less hours in comparison to the LBT?
I picked a row of points, going from the front to the back of the facade, so see the difference between the two engines. The results are below and I was quite surprised, it’s not a linear difference, how could you explain this?
The suggestion for the boolean option isn’t a bad one but it’s something that is currently difficult to implement given how the recipe workflow language is written. Also, if we were to offer a type of study that accounted for direct irradiance, it should really be a separate metric with a separate name to avoid confusion. So it follows that it should probably also be a separate recipe (maybe something like “direct sun irradiance” or even “annual sun exposure” if there’s an input for occupancy schedule and illuminance thresholds).
Yes, if you are going to do a comparison between Ladybug and the Radiance recipe, make sure that you are plugging in hoys with a half-hour like so:
The current bug in the “Direct Sun Hours” recipe is related to hours where the DIRECT NORMAL RADIATION is zero because of cloudy conditions. It has nothing to do with the GLOBAL HORIZONTAL RADIATION.
The issue is completely fixed in the development version of the Grasshopper plugin now. So you can get the fix using the 'LB Versioner" component.
The recipe will now produce results similar to the “LB Direct Sun Hours” component. The only (potential) difference is that the recipe will use sun positions on the half-hour whenever a Wea with a timestep of 1 is used.
yes, I adjusted the hours in the input and in the output, so that they fall in the same period. I believe that the difference is related to the calculation engine and its resolution. See the picture below, I made some little changes to Chris’ gh file so that the output of the two can be compared hourly. You can see in the results below that the two methods disagree more when the window frame is used, and less when it’s not.
You say 13 hours, I say 2% error, which is very acceptable more seriously, I think the difference is irrelevant at the moment as I suppose you cannot say with 100% certainly that Ladybug’s method is the most accurate one.
What I wanted to try but was unable to was to increase the resolution of radiance’s calculation to see if that would have a big impact in the results, but the option is hidden under the hood.
more seriously, I think the difference is irrelevant at the moment as I suppose you cannot say with 100% certainly that Ladybug’s method is the most accurate one.