Grasshopper

algorithmic modeling for Rhino

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?




Views: 1012

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

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:

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:

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.

I opened this issue.

Hopefully we will get an explanation.

-A.

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

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.

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

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 ignoredLink 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.

...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.

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

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service