Where to insert window descriptions to ensure they are used?

I have a puzzling problem to do with changing the window description in the input to the calculation in EnergyPlus, but I am finding that EP ignores this setting and does its calculations using a default value.

I create a construction set like this:

This links to the EP building model like this:

(Note: on the left are the surfaces creating the roof (1), walls (4), floor (1). and windows

Just to the right of these geometries defining the 6 surfaces that are the Honeybee “Faces”. These are then fed into the one Room generator . This last is also where the Construction set links into the EP model

After this, the script adds windows as a %age, and adds shade outside the building. The only option to add a construction set prior to the model run part of the script is apparently not relevant as the EP properties to be entered for glazing % and shades relates to the specific object being added, not to the construction set.

And yet, the glazing definitions incorporated into the construction set is clearly being ignored.

I’d appreciate any assistance you may be able to provide on this.

For this case it will be helpful to attache a simplified version file with the issue.
Construction sets usually work for me smoothly, so it will be more effective to check the file.
-A.

Kia ora @AbrahamYezioro … simplification! That is what defeats me at present. Hence the process tracking screen captures. I will attempt it, but I suspect it is the complexity that is killing my QA processes. I was hoping there might be someone who has encountered this and could suggest what to look for. The script looks like this:

nga mihi
Michael

Hi @MichaelDonn, I think @AbrahamYezioro was asking for your actual Grasshopper definition (ideally a simplified version of it).

If I understand your issue correctly, it is that you are assigning a custom window construction but it gets ignored by HB? If so, how did you check whether this is actually the case?

Here is a quick test where I don’t assign constructions:

And here is what happens when I do assign a window construction:

As you can see, in this case there appears to be no issue. In your case, I suggest starting as simple as my attached definition, then incrementally adding your other components to see at which precise point it fails for you. Or, upload your definition :grinning:
unnamed.gh (27.7 KB)

1 Like

5Zone-Revised_2021-8-11-revisionoptionsuplifted.gh (1.1 MB)

I take the point about starting simply. That is where I was at, some months ago. Happy for people to play with this, but I was concerned to check the integrity of the script as I am working with it, because it might have been some extraneous issue created by the manner in which I was making the geometry customisable and the general complexity of what i was trying to do. I was also unaware of how to simplify other than via the screen captures. Also, while the script is a work in progress, I was wary of asking people to search through it in order to answer the question I was posing.

I have what I would term a workaround, but I am thinking this might be a suggestion for how to code the next version of the tool(s).

Down here in the material definitions from which the script users can choose the inputs to the construction set:

We create a construction set.

This construction set is then fed into the rooms that eventually make up the models.

Like this:

So far so good.

In terms of constructions:

image

These rooms are then fed into the adjacency check and then the glazing by ratio setup

And this produces the following constructions:

image

No matter what I did with the options for the construction set glazing input, nothing changed from this generic double pane attribute that was produced by the glazing by ratio operation.

I noticed this when testing the script and choosing single glazing, or triple glazing inputs produced no performance difference!

The somewhat unsatisfying solution turns out to be to apply the window construction after all these other operations

image

Unsatisfying because I am effectively inserting it into the construction set and adding it on its own… but it works!

image

And just to confirm the other options in the script are working: if I change the ceiling and floor options from adiabatic to outdoors, the relevant constructions from the construction set are carried through from the room definitions to the model.

image

Sorry @MichaelDonn the definition is way too huge and complex - I think you might have trouble finding someone who is willing to spend time debugging it that way. By “simplify”, I meant copy-pasting a single zone from your model into a fresh definition and making it readable. Currently your definition is really hard to follow - everything is located super far away from one another, there are many different design options that are copied next to each another, there are way too many hidden wires so one is left chasing them around the definition…

Having said that - are you aware that HB makes a distinction between operable and not-operable windows? In your construction set, I can see you have plugged a construction into “window” but not “operable”. If your windows were set to operable then I think that’s the reason why the construction was ignored.

Just to confirm @MaxMarschall comment. In the definition of construction sets you have two inputs for windows, one for operable and the other for not operable. You need to give an input for both, otherwise the default values are kept.
-A.

Kia ora folks

Thanks for taking the time to look.

I understand the complexity of the script, and was not wishing to ask people to look through / debug the whole thing, hence my attempt to take people through the salient parts. To build a 1 zone version is a significant extra modelling time, and risks missing the error that the script itself induces. This is the reason for my salient screen captures.
I reluctantly posted the whole script on request.

To address the new issues in turn:

  • I have checked the window open control and the constructions assigned to the building before and after it has been applied are consistent …
  • I can see that there are two options in the construction set definitions for windows, one of which is for apertures where the option is set to openable, but this is now even more confusing to me:

IF, when defining a construction set, I set the window to be aperture type “operable” like this:

THEN after the construction set is applied to my rooms and these rooms are solved for adjacency and a % window area has been applied to the outdoor facades, the selected window construction is carried through to the model

This results from applying the construction facade visualisation here:

image

BUT

IF I apply the window construction as a “Window” like this:

THEN that same construction visualisation produces these constructions:

The glazing properties only appear properly after we have applied the glazing definition again:
image

Then we revert to what the building (glazing) constructions should be.

M

Didn’t manage to navigate in the file. Sorry.
Get to a part where i want to demonstrate the principle of the construction set. See the image below:


I set both inputs, window and operable to the same construction for the window. In this way you can be sure that the construction will be applied for both options. If you have in the model some windows that are operable and some that aren’t you can set different constructions accordingly.
Hope this helps,
-A.

Hi

Yep. I was not expecting people would want to track through the forest of geometry definitions. Thanks for following through on this.

I understand that what you suggest will work. My puzzlement is why the “Operable” window definition in a construction set would be carried through from the room definition to the window aperture creation and thus be applied to the openings, but the same would not happen with the “Window” definition fed into the construction set.

More investigation to follow. I want to identify now how your suggestion of feeding two different window definitions into the construction set would carry through to the model.

M

Thank you so much to those people who have taken the time to respond to my puzzlement, and thus help with my thinking.

The whole self-inflicted mess arises from the desire for the users of the script to be enabled to explore the benefits of openable windows for cooling compared to full air conditioning.

In the inputs they can choose are these choices:

Choosing to make the “windows openable for cooling” feeds a yes/no into the last option on the “Apertures by ratio” function.

IF this is set to true (windows ARE openable) and the only input to the subface construction subset is for “Window” then there are no properties for the openable windows being passed from the Room definition to the aperture definition:

So, in the absence of an openable window definition for a room, the aperture by ratio function assigns a generic window construction.

I can see that logic, I am now about to ensure that for every window glazing type/construction, I am calculating an opening type (calculated via LBNL’s Window program) construction.

Thus, I will be registering the properties of this assembly for openable windows:
image

And for standard windows:
image

With options for framing as part of the selection, as well as glazing type.

Thanks for all the assistance. I am pretty sure my logic of how I thought the construction sets were working would never have identified this on my own.

1 Like