Creating dynamic window error

Hi,
I’m trying to use LBT 1.2.0 to simulate a project with some electrochromic window, but the Openstudio doesn’t work correctly with this error:

  1. ** Severe ** CheckAndSetConstructionProperties: Error in window construction WINDOW_WITH_SHADE

It seems something wrong when I set the “window construction shade” component. I upload the file here
example.gh (104.4 KB)

How can I make it correct? Many Thanks!

I tried the same simulation in using 1.3.0, but there is still the same error.
Here is the new file: example.gh (72.9 KB)

The idf document shows that there are only 2 layers of the shading glass, which is different from the setting.
image
image

Thank you for reporting this bug, @Yang , and I’m so sorry that it fell through the cracks a few months ago. FYI, if you find any more cases like this that are pretty confidently a bug, you should feel free to use my @chris handle in order to make sure that I see them.

In any event, I just pushed a fix for this case into the development version of the plugin (as part of a new feature that I just added):

Everything is simulating correctly on my end now:

You should be able to get the fix on your end with the “LB Versioner” in an hour or so.
Thanks again for reporting!

1 Like

Hi Chris,
Thank you a thousand times, it works fine on my end now.

1 Like

Hi @chris,
There is something i don’t get in the process you suggest above (using the single pane as shade material).
My understanding is that, when the schedule is set, the whole window will be triple paned (the original double pane + the single pane).
From the explanation i read that, at scheduled, the window will be single pane and when not scheduled, double. This is what doesn’t makes sense to me. For this situation i would think of using the WindowCOnstructionDynamic component.
Do you mind to give some light here?
Thanks!!
-A.

Hi @AbrahamYezioro ,

I understand your confusion but EnergyPlus’s Shading Control does not natively support the type of construction that you are describing and you would have to use a WindowConstructionDynamic to model a construction where the number of glass panes change dynamically. When you plug in a glazing material as a _shd_material for a WindowConstructionShade, then it must replace one of the layers in the parent window construction to which it is assigned. So selecting Exterior for the shade location would ensure that the glass _shd_material replaces the outer pane, selecting Interior replaces the inside pane, and Between can be used to swap out the middle glass pane for triple pane constructions.

Let me know if you think there’s any way to change the component descriptions to make this more clear.

Hi @chris,
Thanks for your prompt answer.
Unfortunately i’m still confused.

Let’s say that in the “normal” use of the _shd_material input, if i plug a shade/blind material it will be inserted according to a schedule (in case schedule is the trigger). It is not replacing any other layer. For the sake of the example, if i have a double pane glazing as the construction, it will remain and an additional layer will be added to it, which is the shade itself.
So far, so good … i think.
Now you say that if the _shd_material is a glazing material the behaviour is different and it changes/replaces one of the layers of the construction instead of adding an additional one?
If so, so far, not so good …

Sorry, but this is confusing and is shaking some basic understanding. In any case i’ll try to check the IDF and outputs and see it it makes sense.

This is a standby for me. I really hope my understanding is the right one … :slight_smile:
Thanks,
-A.

Hi @AbrahamYezioro ,

I think your explanation already makes it clear.

The output will be different according to what the shade material is. As the graph shows, if there is a normal shade, the output construction has 4 layers, while if there is a glass material, the output construction only has 3 layers, which means one of the original layers has been removed.

Thanks @Yang,
I learned something new today. I wasn’t aware of this possibility, which is kind of cool.
Now it is clear.

@chris, the component description is fine. I didn’t pay attention to the second part of it:

… or a dynamically controlled glass pane

-A.

Thank you for the feedback , @AbrahamYezioro and for pointing out some of the things that show how the components is supposed to work, @Yang .

When I had designed this WindowConstructionShade object, I had thought that it was clear but I think that’s only because I was comparing myself to how these constructions are represented in IDF, which is really confusing and probably too low of a bar to compare a UI to. I am all for making things clearer on the plugin side. It would be a pretty big effort to make a separation like WindowConstructionShade and WindowConstructionSwitchable in the core libraries but I would be open to separating the switchable glazing features out into a separate Grasshopper component in order to make it clear that the _shade_material is interpreted differently in that case (maybe we call it _switched_on_mat on this other component).

Let me know if you think that would mitigate some of the confusion that happened here and I can make the separation when I get the chance.

Hi @chris,
You are so great! This is a good idea. Whenever you have the time. Really not a number one in the list.
The truth is that in my case this is the first time i’m aware of this option and not that necessarily i need to have/use it … but good to know it is out there.
Thanks,
-A.