I’m trying to simulate the amount of solar radiation incident on building walls.
I once got the result with ladybug-tools, but it looked strange when viewed together with the epw file used for the simulation.
So, I checked how the simulation goes and found some curious points.
I show a picture which displays the sun position and the skydome at 1st Jan 11:00.
In the picture, I circled the position of the sun with a green line (for readability).
The picture shows that the sun position and the high radiation zone do not match.
This happens at the other times as well.
Also, the skydome radiation disappear even if the sun has not set at 16:00.
The epw file says there are more than 100{Wh/m2} of radiation 16:00 on Jan 1st.
(I’m sorry I can post only one picture because I’m a beginner.)
Are these things cased by bugs?
I believe these things never happen if the simulations work correctly.
In the discretized sky for daysim and other simulations the direct sun is divided among the closest 3(or4?) Patches in the sky. So you would have to add all the values from the 3-4 sky patches to get the real direct radiation(ish).
Also careful that the legend is kW and you mention W, so 0.5 kW/m2 (or sometimes mentioned as [0.5kWh/m2,h] is the same as 500W/m2.
From the look of your screenshot it looks like either your sun or the sky is shifted for daylight saving times or different time zones. Looks like there is an hour of difference on the position.
Or
In Daysim for instance (and I think in all of the climate based skies) the input data for 15 o clock is actually average between 15 and 16, so timestamp 15:30. @mikkel might know the details better than I do
I calculated the sun position by myself and confirmed that it was correctly calculated in Ladybug.
Also, there is nothing in my Grasshopper code that would cause a daylight saving time or time zone difference.
Judging by these things, the time of the skydome is incorrect.
In order to understand the result more easily, I made bar charts below.
This figure shows the direct solar radiation to the horizontal plane at every hour on January 1st, calculated by Ladybug and simple way( {direct normal radiation} * sin{solar altitude} ) respectively.
Comparing this result with the Direct Normal Radiation which is contained in the epw file, we can see the result from Ladybug is obviously strange. (especially look at night)
I think this cannot explain the result of 15 o’clock. The value by Ladybug is too small.
In addition, for west/east facing vertical plane, the difference causes more than 10% of difference between the annual solar radiation calculated by Ladybug and simple way.
Is this a big difference, isn’t it?
Any way, the discretized sky looks like incorrect (time? sun position?).
I strongly suspect a setting error of Ladybug…
Or am I making a big mistake?
Daylight savings is not a bad guess but I am fairly confident that this is not the cause and it’s instead because the radiation values in the EPW are for the half hour and not the hour (eg. 11:30 and not 11:00). So, if you are looking to align the sun position with the radiation values of an EPW, you should be plugging in 11.5 for the SunPath hoy and not 11.
This is just the way the EPW data is written it’s an idiosyncrasy that DAYSIM (and also Ladybug Tools) has to inherit from EPW data.
I checked the reference of EPW and confirmed radiation values are not for the hour indicated.
But it may be mistake to use the sun position of 11:30 at 11:00.
This is in conflict with this reference:
Field: Direct Normal Radiation
This is the Direct Normal Radiation in Wh/m2. (Amount of solar radiation in Wh/m2 received directly from the solar disk on a surface perpendicular to the sun’s rays, during the number of minutes preceding the time indicated.) If the field is “missing ( 9999)” or invalid (<0), it is set to 0. Counts of such missing values are totaled and presented at the end of the runperiod.
Ladybug looks like using a sun position that is 30 minutes ahead of the displayed time.
But, shouldn’t it use the time 30 minutes before? (10:30 for 11:00)
Yes, you’re correct @Kta . Sorry for the confusion. I should have said “(eg. 10:30 and not 11:00).” So plug in 10.5 for the EPW hour 11 and the two should be aligned.
