Illuminance discrepancy from Honeybee grid based, Honeybee[+] grid based, and Honeybee[+] annual

[Xiufang]

Dear all,

While transferring model and simulation from Honeybee to Honeybee[+], from the help from this forum I was able to run both grid based and annual simulation in Honeybee[+] with daylight coefficient recipe. However I found the result difference is large. I was wondering if anyone had the same issue before, or there is something wrong with my simulation process.

The 2 gh files has same geometry, same material setting, and same weather file, with same BSDF shade, similar RadPar, running grid-based illuminance test for the same time (12/29 4 pm). The results from Honeybee[+] is as half as the ones from Honeybee, although the illuminance trend (where to be higher and where to be lower) remains the same:
Same wall, result from Honeybee

Result from Honeybee[+]

I was also able to run an annual run at Honeybee[+] with the BSDF material and read the HOY result from annual result, and it is about 30 lux less than the Honeybee[+] grid based simulation, on which my understanding is within the error margin (?). Is this difference caused by different interpretation of BSDF?

There is also another troubling issue while reading the annual result: when connecting hourlyValues to the runRadiance outputs after an annual run, the results for hourly values (for example 12/29 4 pm) is not the results in total…scene…default.ill (in result folder, open in excel and read the row result for a point at 12/29 4 pm) at the same hour. I was really confused by this one. What did I miss here?

Thanks for your help!

Best,
Xiufang
2018.10.10

[mostapha]

@Xiufang,

1. See this discussion: HB+, legacy and DAYSIM results - #13 by mostapha
2. You need to share a simplified sample file that we can use to regenerate the error otherwise it will be really hard to help.

@Xiufang

when connecting hourlyValues to the runRadiance outputs after an annual run, the results for hourly values (for example 12/29 4 pm) is not the results in total…scene…default.ill (in result folder, open in excel and read the row result for a point at 12/29 4 pm) at the same hour. I was really confused by this one. What did I miss here?

I assume you are using the latest version from GitHub? If you don’t then you should update your installation using Update Honeybee[+] component.

[Xiufang]

@mostapha,

Please see the post below directly for updates on this item. The sample file can be downloaded from this post. Thanks!

Thanks! I read the discussion and updated my Honeybee[+] to 0.0.05, and generated a simplified test box gh file (learnt from HB+, legacy and DAYSIM results).

This test file TestBox_HB_HBPlus.gh (577.9 KB) contains the Honeybee, Honeybee[+] annual, and Honeybee[+] point-in-time script I used to test a 10m20m5m box with west facing glass (Tvis 0.6) and a interior shade with BSDF material from LBL Window 7.6 library 2011-SA28.7z (3.2 KB). Weather file CA Fullerton: USA_CA_Fullerton.Muni.AP.722976_TMY3.7z (169.7 KB)

The test is for 12/29 4 pm. However the discrepancy between Honeybee and Honeybee[+] is still large. I was wondering if there is some mistake in my script…

Also the result shown on the HB Plus Annual 12/29 4 pm reading still does not match with the total…scene…default.ill file. Reading from .ill file directly the result shown as below (middle part, not colored):

I also tested with glass only (no shade BSDF connected) to see if this was caused by BSDF material, but the results remain quite different:

Also it may be minor: dose Honeybee[+] only round down for illuminance value? E.g. 100.9 lux will shown as 100 lux mapped on the grid?

Thanks for your help! Any directions about what possible went wrong would be much appreciated!

Best,
Xiufang

[Xiufang]

Hi @mostapha

Updates on the post above:

I took out the BSDF material shade, just testing a box with west facing glass. Also added test point (facing up) outdoor to see the sky. Then I found:

1. Somehow the 1 hour behind issue still exists in Honeybee [+] component ClimatebasedSky (0.0.04 Feb 7 2018), when the time is set to 12/29 3 pm, it is showing the same radiation value as Honeybee genClimateBasedSky at 12/29 4 pm. Screenshot below:
   
   

2. After setting the hour back by 1 hour for Honeybee[+], the results are below for outdoor test point and floor-wall test surface:
   
   
   
   
   

However if I generate sunpath via LadybugPlus, the sunpath as below, it looks like although Honeybee[+] climateBasedSky is taking 4 pm radiation, it is taking 3 pm sun position: is it possible? Is this the reason for the difference between HB point-in-time (Radiance?) and HB[+] point-in-time?

Considering the radiation and location in both Honeybee and Honeybee[+]
ClimateBasedSky are the same, (-w 446.0 101.0, -4 33.87, -o 117.98), my understanding is the difference between HB+ point-in-time and annual is because " In the annual run we use the gendaylit.py and sun position is calculated using the SunPath class ", and it is different for HB[+] point-in-time?

The issue of "the result shown on the HB Plus Annual 12/29 4 pm reading still does not match with the total…scene…default.ill file. " still remains.

Thanks!
Best,
Xiufang

[mostapha]

In the legacy version hours are from 1-24 but in [+] plugins hours are from 0 to 23.

@Xiufang

The issue of "the result shown on the HB Plus Annual 12/29 4 pm reading still does not match with the total…scene…default.ill file. " still remains.

You should check scene…default.ill file.

scene…default.ill = total..scene…default.ill - direct..scene…default.ill + sun..scene…default.ill

[Xiufang]

@mostapha

Thanks Mostapha! So for the legacy version when we input 16 at hour, it should be the same as inputting 15 at [+], both should read the same radiation and sun position from weather file.
But when I was checking the sun path via LadybugPlus, the legacy version (input 15 at hour) and HB[+] (input 16 at hour) are taking different sun position. Is Honeybee[+] climateBasedSky is taking HOY8704 (12/29 4pm) radiation with HOY 8703 (12/29 3 pm) sun position?

Thanks!
Best,
Xiufang

[Xiufang]

I also just tested HB climate based sky and HB[+] climate based sky via sun path. When keeping radiation value the same between 2 skies (by dialing HB[+] 1 hour back), the sun positions are different:

Also attached test file here: Sun Angle.gh (52.7 KB) My guess is in HB[+] when EPW was converted to WEA that lead to the same radiation value matches with 1 hour earlier sun position than in HB?

Thanks!
Best,
Xiufang

[MingboPeng]

@Xiufang
Ok, I think I found the problem: in HB[+], both point in time and annual simulation, sun position is correct, but radiation value that HB[+] uses is not correct. @mostapha

Here are something I checked at beginning:

HOY from LB and LB[+] are same:

Radiations from 29th Dec 4PM and 5PM

HB sky [legacy] :

Here are all tests that I have done:

Test #1~ #4 : trying to run for 29 Dec 4PM, but with different methods.
#2~#4 are meant to understand what happened to #1 test result.

In #2: set to 4pm, but radiation value it takes from 5pm, because #2 equals #4.

In#3: set to 4pm, but I manually use 4pm radiation value from EPW. the result matches the Legacy PIT.

In#4: same setting as #3, but use radiation value from 5pm.

So until here:
we can see from #1,
its direct value = #4’s direct value (-ab 0) (let’s discuss if these are really the same at another place)
its diffuse value = #4’s diffuse value (set dir 0; dif 73).
But #1 doesn’t equal #4, here is the reason:

#4 dir + $4 dif = #5
#1 = #5

Now here is a question: why #4 ≠ #5? @mostapha @sarith
My guess is: in point in time simulation: #4 = #4 dir + the second and more bounces from #4 direct light + #4 dif.

Tested GH file: PITvsAnnual.gh (647.5 KB)

Hope this helps,
-Mingbo

[sarith]

@MingboPeng There is too much info on this thread for my tiny brain to digest . I think @mostapha will have the answers. By the way, what is HB[0]? The Ironbug version?

@MingboPeng

Ok, I think I found the problem: in HB[0],

[MingboPeng]

@mostapha

scene…default.ill = total…scene…default.ill - diffuse…scene…default.ill + sun…scene…default.ill

isn’t it should be
scene = total..scene - direct..scene + sun..scene?

[MingboPeng]

Sorry for the late night typo…meant HB[+]

my understanding is: scene = total..scene - direct..scene + sun..scene

Is that possible that:
in both total..scene and direct..scene are using 5pm (1 hour after what is asked, meant to test 4pm), and in sun..scene , the sun position is using 4pm data, but sun’s radiation is from 5p?

[sarith]

@MingboPeng

my understanding is: scene = total..scene - direct..scene + sun..scene

Yup, this is also correct. There is recurring confusion regarding the diffuse direct part. The reason the second term is called direct-difuse is that the sun patches are “found” through probabilistic Monte-Carlo ray-tracing (this is -ab 1 in the case of rtrace, rpict, rcontrib etc). When we do the calculation for the third part we do not rely on Monte-Carlo ray tracing at all (hence -ab 0). A single ray is shot directly to the centre of the sun (which is a light).

[Xiufang]

Thanks @MingboPeng @sarith!

Thanks for your test and help! I followed up with 3 items mentioned in your posts:

1. Based on the current results file after an annual run, the results shown on the mesh (scene…default.ill) is indeed from scene…default.ill = total…scene…default.ill - direct…scene…default.ill + sun…scene…default.ill`.

2.For HB[+] annual results/sky, wea file carries the right radiation at each hour comparing with the epw file, the 12/29 16 Direct Normal irradiation (446) and Diffuse irradiance (101) were captured in wea file at hour 12/29 15.5. For the next hour (17 in epw and 16.5 in wea), the numbers are 191, 11 respectively.

3. For HB[+] PIT, when test time is set to 12/29 16, the climate based .sky file shows:

In this case, it does show that HB[+] climate based sky reads EPW 17/WEA 16.5 irradiance data for sky. But the solar altitude and azimuth is similar to the read of sunpath at 12/29 16.
(my guess is the azimuth counts south as 0 then clockwise? So 234.7-180=54.7 )

What I found also seconds in both HB[+] PIT and annual

@MingboPeng

the sun position is using 4pm data, but sun’s radiation is from 5p

@mostapha any input from you would be very helpful and much appreciated! Thanks!

Best,
Xiufang

[mostapha]

Hi @MingboPeng and @Xiufang, There is so much going on here in one topic but I try to address the main questions here.

Wea file

For all the annual simulations as you both pointed out Honeybee uses wea file to generate the sky. Wea file is originally used by Daysim (https://daysim.ning.com/page/daysim-file-type-daysim-weather-file) and include direct and diffuse irradiance/radiation values for each hour. Honeybee exactly follows the structure of the file.

Direct and diffuse radiation values are cumulative values that are measured during the last hour. For example the value for 12 29 17 in the weather file is measured from hour 16 to hour 17. Now what would be the best sun position to represent this value? Wea uses the time between the start and end (16:30) in this case. That’s the position that we also use in Honeybee[+].

Point in time climate-based sky

We use the same logic in point-in-time sky component so the radiation values should match but the altitude and azimuth in gendaylit is calculated using Radiance and not Ladybug sunpath. Ladybug is actually more accurate. The inaccuracies in Radiance sunpath are known but they are not major. See here:

Radiance sun position formula, solar position algorithm

We can address this by using gendaylit -ang altitude azimuth option instead and calculate the sun position from Ladybug. Haven’t thought about it before but it is totally doable.

[Xiufang]

Thanks @mostapha !
I read the radiance-online post and compared HB[+] sun angle with NOAA calculator and the sun position difference is almost within 1 degree. The issue we have could be summarized in the image below. If the Honeybee[+] 12/29 16 is actually testing 17, taking -w 191 11 from wea file 12 29 16.5, shall it use the sun position of 16.5? The 8.1, 54.8 is 16:00 sun position comparing with NOAA.

Thanks!
Best,
Xiufang

[mostapha]

@Xiufang

I read the radiance-online post and compared HB[+] sun angle with NOAA calculator and the sun position difference is almost within 1 degree.

It is not Honeybee[+], it is Radiance. We should not confuse:

1. Radiance and Honeybee[+]: 8.1 and 54.8 are from Radiance and they are calculated by radiance based on your input for hour 16. If you want to calculate the sky for for hour 16:30 then input 16.5 for the hour. In any case the altitude and azimuth that you are point to are coming from Radiance gendaylit and not Honeybee[+]. If you check the output from Honeybee[+] sunpath it should match the values from NOAA.

2. Annual and Point-in-time simulation: For annual simulation Honeybee[+] does use 16:30 for simulation as you suggested. For point-in-time simulation gendaylit simply generates the sky based on user input. As I said if you want the sky for 16:30 then you need to input 16.5 for the hour. These two are not really related to each other.

Nevertheless, We should probably get the hour in HB legacy to match HB[+] and WEA file.

[Xiufang]

Thanks @mostapha ! Based on the further conversation I summarized what I understood as below. But please feel free to comment or correct if I were wrong. Thanks!
Note: this chart is only a reference which is based on 0.0.04 Honeybee [+] and Honeybee 0.0.63 since the future versions may get the hour in HB legacy to match HB[+] and WEA file.