Window shade generator (sometimes) won't output HB object.

Hi!

And thanks for all the great work. I'm having the following problem with the HB window shade generator.

Ive been trying to produce shading and discovered that the different versions behave differently - same input given. The concern is that the newer version seems to not produce any HB objects while the old one did. When using version .58 and setting it up as can be seen in the "first error..." file below I am able to succesfully produce a HB object.

However: Why am I not able to produce a HB object when using _numofShds? I can only get it to work using _distBetween. Why is this? This is my main question, the following one is a possible bug report.

When using the exact same setup as used in the .58 version that did produce a HB object on the .60 version it will not produce anything at all. And when I have them both in the canvas simultaneously (I realize its a sketchy thing to have two versions of stuff at the same time) the .58 gives me another error about materials input and EPfenSurface, as it turns red. This can be seen in the other file I input submitted.

What should I try?

Attachments:

first error EnergyPlus_Window_Shade_Generator.gh, 634 KB
shade generator error.gh, 567 KB

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Abraham Yezioro on November 10, 2016 at 9:15pm

Hmmm ...

You are right Ludvig. The component works ONLY when it outputs at least 2 shades (for the HBObjWShades give an output). Please open an issue at the github ... unless this is what Saeran is working on ... not sure.

See attached some way to work this around in the meanwhile.

Sorry for this confusion.

-A.

Attachments:

EnergyPlus_Window_Shade_Generatorversion60_AY.gh, 493 KB

Permalink Reply by Saeran Vasanthakumar on November 10, 2016 at 11:55pm

Interestingly enough, it looks like the component is working as intended.

This seems to be the reason why one shade won't work in this example:

https://github.com/mostaphaRoudsari/Honeybee/blob/master/src/Honeyb...

Basically, Chris has added a check to see if the shadingHeight (the distance of the window to shade device) is greater then one meter, which then cancels the generation of the HBObject, to make sure it doesn't crash E+. I'm not sure why, it crashes E+, but I'll raise this as an issue on github, to see if this is, as it seems, an edge case that will never give us a HBObject, or if there's a way around this problem.

Unfortunately I also don't have any solution for this, but here's a file where I've reduced your window height (therefore the shadingHeight) to less then one meter and the component works fine. Maybe that will be of some help in the meantime?

Attachments:

EnergyPlus_Window_Shade_Generatorversion60_AY_SV.gh, 491 KB

Permalink Reply by Ludvig Haav on November 11, 2016 at 4:34am

That is a strange limitation to put in there, I hope it is not native to E+ so that it might be remedied. I will find a temporary work around then with windows that I divide in 2 surfaces. Happy I found an issue so that this might benefit more people. Thanks for all the help, really.

Permalink Reply by Abraham Yezioro on November 11, 2016 at 11:15am

I opened this issue.

Hopefully we will get an explanation.

-A.

Permalink Reply by Chris Mackey on November 24, 2016 at 6:01pm

Hello All,

Thank you for asking and sorry for the late reply. This limitation is native to E+ and affects the E+ blinds object:

http://bigladdersoftware.com/epx/docs/8-5/input-output-reference/gr...

The simple E+ parameterization of the blinds is just not accurate when the shadeDepth, distToGlass, or distBetween is greater than 1 meter. For these cases, you should plug the generated shadeGeometry into a "Honeybee_Context" component in order to factor it into the simulation. As a general rule of thumb, any geometry that is larger than 1 meter should probably be simulated using the "Honeybee_Context" component for now.

In the future, I had planned to possibly assingn E+Overhang or Fin objects to the windows, which can be larger than 1 meter and thus could be ouput from the HBObjWShades for some cases. For the time being, the Honeybee_Context is the best way to deal with this case, though.

-Chris

Permalink Reply by Abraham Yezioro on November 25, 2016 at 12:23am

Hi Chris and thank you for your answer.

I believe this is clear now and should be clear before. But now i think there is a misunderstanding in the use of the component or the definitions/inputs in it. Probably for this case Ludvig should be using the HB_EPWindowShades ONLY for the external shades (that should be used as context, as Chris said), and use the HBZones output from the previous used (in the flow of the connected components) HB_createHBZones. In this way there is no need to split the window in smaller parts as Saeran did.

BTW, i didn't find the 1 mt limitation in the definitions ...

BTW #2, What are the assumptions of the slats angle, and other definitions that are not in the component's input?

Hope this makes some sense now for all of us.

Thanks,

-A.

Permalink Reply by Chris Mackey on November 27, 2016 at 6:44pm

Abraham,

Thanks for the clarification. Yes, there should never be a need to split the windows in two. You use the HBObjWShade if the component produces them and, if not, you plug the shade geometry in as context surfaces.

The slat angle is included in the component (that is what the "angle" input refers to). However, I did not include the ability to schedule a dynamic slat angle as the component was already so large and I had doubts about whether this feature would be used. I can work it in if there's demand for it.

-Chris

Permalink Reply by Ludvig Haav on November 30, 2016 at 5:13pm

Thanks for the clarification. I will make due with context surfaces then. They are actually meant to be PVs and while reading through the E+ documentation of the heat transfer integration modes of the PV-modules I realize that using PVs might take me a little step closer to thermal integration of the overhang geometry in the zone calculation. However it does say in the input/output reference that "The input fields for Module Heat Capacity and Module Heat Loss Coefficient are ignored" Link in the integrated modes, so in the end it doesnt make me much wiser how they are calculated. Looking in the Engineering reference it says that "If the user specifies “Integrated Surface Outside Face” for this parameter, then the temperature result from EnergyPlus’s modeling of surfaces is used for the cell temperature." "Link"

Does anyone know how they are calculated? As in if the PV-surfaces also affect the surface temperatures of other surfaces nearby, or if only the surfaces nearby affect the PV-temperature.

Permalink Reply by Ludvig Haav on November 30, 2016 at 5:19pm

...adding overhangs (and fins) would indeed be appreciated. But I guess your todolist is long. : )

My wish for christmas this year is that E+ rewrites context surfaces to allow material properties and mass to be assigned to them.

Permalink Reply by Chris Mackey on December 1, 2016 at 5:15pm

Ludvig,

You and I both have long E+ wishlists. I think at the top of mine would be the ability to perform detailed solar calculations for non-convex zones:

https://github.com/NREL/EnergyPlus/issues/4839

-Chris