Global variable ShadeType_ not defined when using Honeybee 0.59

Hello HB+LB community,

I am following the Shading Benefit example on Hydra (http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&for...) for a project.

I was having compatibility issues so I decided to upgrade most of the components to Honeybee 0.59. However, now I get an error that states:

"1. Solution exception:global name 'shadeType_' is not defined"

I noticed that the version 0.58 has an input for the shadeType_ but it's no longer available in 0.59 so I'm not sure how to get it functioning.

Thank you,

Justin

Attachments:

EnergyPlus_Simulation_wShading.gh, 610 KB

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Justin Shultz on March 29, 2016 at 11:23am

I discovered when the Shade Generator component was updated from v0.58 to v0.59 the shadingType_ input was not added to the component. I dropped in the v0.59 Shade Generator and the input is now available.

At the moment, plugging in the cooling loads of the building to the zoneData is freezing the simulation so I'll see what I can do.

Permalink Reply by Justin Shultz on March 29, 2016 at 11:30am

I now receive a new error that is more confusing:

"1. Solution exception:KeyError"

From the read me:

No shades schedule has been connected. It will be assumed that the shades are drawn when the setpoints are met.
Runtime error (KeyNotFoundException): KeyError
Traceback:
line 1015, in createEPBlindControl, "<string>"
line 1185, in main, "<string>"
line 1230, in script

Permalink Reply by Mostapha Sadeghipour Roudsari on March 29, 2016 at 1:01pm

Hi Justin,

Did you try to update the whole definition using update components and then recompute the definition? All the errors seems to be because of version discrepancies.

Mostapha

Permalink Reply by Justin Shultz on March 29, 2016 at 1:33pm

Hi Mostapha,

Thank you for the reply. I have now updated each component piece by piece with better success. However, following the Shading Benefit example on hydra with updated components to v0.59 freezes my Grasshopper. Running the EnergyPlus simulation is fine but when doing the shading benefit part the program freezes. Might there be something holding up the simulation?

Justin

Permalink Reply by Abraham Yezioro on March 30, 2016 at 12:00am

Hi,

I can see that there is a change between the hydra version and the updated version of the HB_EPWindowShades components. Specially with the last input items (data1, 2, 3), which in the new there is only data1.

I've tried adding the inputs in the component but the file works endlessly, so i assume some clarifications regarding those inputs will be welcomed.

Also in the HB_EnergyShadeBenefit inputs it is not clear now (for me) how the output of the Shads must be connected regarding the heating/cooling loads and beam gain inputs.

-A.

Permalink Reply by Chris Mackey on March 30, 2016 at 7:36am

Justin,

Glad that you were able to update the file.

Keep in mind that the shade benefit calculation usually takes a good 2-5 minutes to complete. It is projecting over 4000 sun rays from each of the 100+ test points on each of the windows so it's fairly computationally intensive.

Just give it some time and you should get the result that you see on the Hydra example. I might also recommend running it for just one zone if you need faster feedback.

-Chris

Permalink Reply by Justin Shultz on April 7, 2016 at 9:50am

I experienced a similar problem as Abraham. When configuring the model to study benefits of shading the file runs endlessly. I let it run for 7+ hours and at the end did not receive any results.

Permalink Reply by Chris Mackey on April 11, 2016 at 10:55am

Justin and Abraham,

Sorry for not looking deeper into this before. I didn't realize how much the new capabilities that I had added to the zone shades component had damaged the shade benefit workflow. The big reason why the component was running endlessly was that when you add zoneData2_ and zoneData3_ inputs to the component, they were not being set to Tree access automatically (each item of the tree was being evaluated and this was causing the component to run 8760x4 times). The assigning of tree access now happens automatically. The attached file should work well without complications.