Different results in 3-phase run after updating Honeybee+ from 0.0.05 to 0.0.06

I recently updated Honeybee+ from the version 0.0.05 to 0.0.06 released this summer and I am having different results after running the same script where I updated all the components. Is a three-phase analysis so it involves the use of BSDFs but I haven’t changed anything in it so I don’t know where the differences come from. At first, I also updated Radiance from 5.1 to 5.3 so, thinking that the issue could have been in that, I tried also the 5.2 and 5.1 version but the problem is still there. I can understand that sometimes between different versions there could be some slight differences but what I have is a difference of 15 percentage points passing from the previous average cDA for the room of 10% to the actual 25%. Another strange thing is that now the distribution of the light in the room looks ununiform in relation to the windows, like if something in the sky is somehow wrong or “shifted”.
I would be really glad if someone could explain to me what is going on here.
Thank you in advance,

BSDFs, EPW_file.zip (1.0 MB)

UPDATES and possible solution

Before I forgot to mention that among the rest I also updated Rhino from version 5 to 6. I actually tried to rerun the analysis on Rhino 5 and I get the lower results of before, so looks like the difference is related to the Rhinoceros version.

So, my question now is, why does that happen and which of the two results is more reliable?
Would be nice to have a brief explanation of the issue since I would like to pass to Rhino 6 in the near future but without worrying about having different results.

Thank you,

This is pretty odd, @Matteo . Can you check and see if the .rad and .mat files that are written out by the two versions of Rhino are the same?

Hopefully @mostapha or @sarith knows more here since they wrote all of the code for the 3-phase recipes on Honeybee[+].

Hi @chris and thank you,

I compared the two .rad files and yes, there is a difference, I don’t know where to find the .mat
Any idea where this comes from? Looks like a problem related to the geometry, am I right?

Hi @Matteo,

Try to check if the up-vector is the same. Look for the file called #_window.glw, I think. It contains something like this:
#@rfluxmtx h=kf u=-0.0,0.0,1.0

Compare the the coordinates of u in each case.

Yup. It might be the vertices getting reordered though. Can you share that file in word form?

Hi @mikkel and @sarith,

I checked the .glw files, there is a difference in the string you were suggesting, do you know what that means and how to overcome the issue and get same results?
Files Rhino 5.zip (1.5 KB) Files Rhino 6.zip (1.5 KB)

See if this solves your issue. It seems to be the same problem.


I have done what you were suggesting in that post @mikkel and it partially fixed the problem, the distribution of light is now uniform and is reasonably following the windows’ geometry. I just have some concerned about the values that I get, I have an average cDA of more than 33%, which is way higher than the more reasonable 10% I get with Rhino 5.

Is the vector now (0, 0, -1)? If that’s the case, try to recreate the surface in order CDAB. I did so and ran a simulation with lower vmtx and dmtx parameters and cDA is 11%.


Yes, the vector was (0,0,-1), I change the order of the point as you suggested to CDAB and now the vector is (0,0,1) and I get 10.2% value as in Rhino 5!

Thank you @mikkel for helping me solve the problem, just one last thing, can we take out of here a lesson learned with a general rule to follow regarding the setting up of the geometry in a proper way or is this a random behaviour of Rhino 6 that we can always have the chance to face in the future?

To say it in few words, is there a way to avoid this issue to happen or should we always give a double check that the vector is 0,0,1 in the .glw file?

Usually it works as expected for vertical windows in my experience but I always check the .glw file. You can hardcode it to to be 0,0,1 somewhere - I can’t remember in which python file. Otherwise, maybe it could be added as an input to the window group component so that you can overwrite the default vector.