This is an odd question, but is it possible that the north rotation is affecting the advanced dynamic shade?
If I do an annual daylight simulation with 0 degree rotation, everything runs as expected. For example, “Illum levels no Dynamic SHD” is 22,338 lux and “illum levels dynamic SHD Group I” is 1385 lux. The shade is doing its job and reducing illuminance.
However, if I include a 45-degree north rotation, “illum levels no Dynamic SHD” is 22338 lux whereas “illum levels dynamic SHD Group I” is 22364 lux. I get the same pattern of results for any non-zero orientation.
I checked the files in the working directory and the *_state_2.rad file appears to be written correctly with the correct trans material. If anyone can help me figure out what’s causing this, it would be greatly appreciated.
Quick update: I tried rotating the zone and shade geometry using the rotate HB Object component and keeping Daysim North at 0. This yielded the same results wherein the advanced shade did not impact zone illuminance.
When I rotated the zone and shade geometry in Rhino and kept Daysim North at 0, the simulation worked as expected. The conceptual shades also worked as expected for any arbitrary north rotation.
I’m afraid that you have spotted a bug. Daysim by default doesn’t support rotating the sky and because of that Honeybee rotates the geometries under the hood. Now that you reported this I wonder if I have forgotten to rotate the advanced shading geometries with the scene. I will check and report back later today whenever I get a chance.
Meanwhile is there any reason that you don’t use Honeybee[+] for this study? It will give you a higher level of flexibility with more accurate results and it also runs faster!
I am actually very interested in this issue as I am using HB for my research study.
I saw that HB+ runs faster, but since I need the lighting profile I have to rely on daysim for now.
The issue is now fixed. Now Honeybee rotates shade geometries as well as additional rad files. I added a number of components to import input files to Daysim back to Grasshopper. This will help to visualize what happens behind the scene.
@mostapha, For context, I’m teaching a class on high performance buildings and the students are using HB/LB to analyze their designs. The last time I used HB/LB in a class three years ago we had many problems with bugs. Ironically, I decided not to use HB[+] because it’s fairly new and I assumed that there were still some bugs to be worked out. Since HB Legacy is older I hoped that most of the bugs had been worked out.
By the way, this is also the reason that I haven’t updated the components since July - the computer lab at school cannot deploy a centralized update to HB/LB so if students individually update individual machines every computer will have a different version.
Nonetheless, your (fast!) support is much appreciated. I’m extremely impressed with how quickly you and Chris have addressed bugs when they are found.
What I meant is that I need the lighting schedule generated by the light simulation ( in this case DAYSIM) for energy simulation. This is something that I raised before in this post and I think that for now HB[+] does not handle.
I wasn’t aware that you’re using them for teaching. I agree that it makes sense to keep using the legacy plugins for teaching for now.
For updating, and with the new updating structure that we have separated update installation and update file, you can copy the user objects in a shared folder and ask all the students to use this folder for updating their installation by setting sourceDirectory to that folder.
When there is a major bug like the two that you found recently it makes sense to update the installation and then use update_file component to update the files. It’s quite easy to update the file using this component.
I’m having a similar issue, even with the updated hb/lb. Funny thing is that this wasn’t happening on previous simulations.
When I try to set the north on the annual daylight recipe it gives me a “rotating the scene error”:
This might be a bit of a late reply for you, but I’ve just been looking through the forums myself to get confirmation on a bug that is still technically part of the honeybee suite, but has a reported work around. See here.
@mostapha, I am still somewhat looking for a confirmation that an annual daylight simulation cannot handle having the north input changed within the recipe. I set up a parametric run over the weekend that changed the orientations for thermal and daylight simulations, but the daylight results errored out whenever the orientation changed away from 0 within the recipe as Mtonellis shows above.
Is it correct that the annual daylight simulation recipe still cannot handle changing the north vector within the recipe, and that instead, we need to rotate the honeybee objects before it is fed into the daylight sim components? If so, can we remove the input for North for the annual recipe component, as it won’t work.
Yeh I believe it is still an issue. If you’re trying to find a solution to this then I still stand by my response. The work around is to rotate the daylight model instead of assigning a north point. This works for me if I take my HB objects just before putting them into the daylight simulation, and use the honeybee rotate component. Unfortunately it gets a bit screwy if you then try to visualise results of thermal and daylight at the same time as map overlays, due to the daylight model having been rotated and the thermal not. Alternatively to get around this you could rotate the thermal model as well instead of assigning a north point.
Hope that helps. I believe the north input still needs to be removed if this error is not being fixed.
