Can OtherSideTemperature BC Allow Apertures?

[edpmay]

Currently, if an OtherSideTemperture BC is assigned to a face, it does not allow Apertures to be hosted on that face:

However, the E+ docs appear to show that Apertures are allowed to be hosted on faces with an OtherSideTemperature BC applied:

Using OSC (Other Side Coefficients) to create controlled panels: Tips and...

Is there a reason that this cannot be allowed within Honeybee? This limitation is causing some issues in a model at the moment.

---

• example.gh (35.0 KB)

---

Currently the HB-face itself checks for if it allows Apertures, which I suppose makes checking against extension BC objects impossible? Perhaps this logic/check should be offloaded to the BC object itself, which could have an allow_apertures attribute flag, or something of that sort?

Alternatively, perhaps OtherSideTempertaure could subclass Outdoors rather than _BoundaryCondition ?

all the best,
@edpmay

[TrevorFedyna]

Hi @edpmay! Hope you are well.
So from what ive been looking at (v24.2 docs specifically) it doesn’t look like a surface using OSC/OtherSideTemperature can host apertures as the parent face will refuse the aps because they themselves can not use OtherSideCoefficients or something?

This is what chat’s saying:

---

can energyplus 24.2 host apertures on a surface thats boundary condition is “OtherSideTemperature”?

Here’s the current answer based on the latest community and documentation interpretations for EnergyPlus 24.2:

Official rule from the EnergyPlus documentation

In the EnergyPlus Input-Output Reference (for base surfaces and their subsurfaces), it states that:

“Windows and GlassDoors are not allowed to have Other Side Coefficients.”
(This is talking about the case where the base surface’s Outside Boundary Condition = OtherSideCoefficients.)

This is the same field used to implement an OtherSideTemperature condition — the prescribed temperature on the other side of an opaque surface.

So by the documented rule, a surface with Outside Boundary Condition = OtherSideCoefficients (i.e., using OtherSideTemperature) should not allow windows/doors attached to it. The logic is that the subsurface could also inherit the OtherSideCoefficients, and EnergyPlus does not support glazing with those coefficients.

What the actual tools/community observe

However, users working with tools like Honeybee/OpenStudio often try to assign apertures to a surface whose boundary is set to OtherSideTemperature and find that the tool rejects it or the simulation errors out — which lines up with the documentation. One discussion specifically notes that if you assign an OtherSideTemperature boundary to a face, apertures are currently not allowed in practice in those tools.

Bottom line (EnergyPlus behavior)

Officially documented: Windows/subsurfaces should not be placed on a surface whose Outside Boundary Condition is OtherSideCoefficients (i.e., OtherSideTemperature).

In practice/tools: Attempting to do so usually fails or is blocked by model editors (OpenStudio/Honeybee) because EnergyPlus doesn’t support it.

Workarounds

If you need a surface with a prescribed exterior temperature and you also want apertures:

Create a very thin “dummy” adjacent zone

Assign the wall as the boundary between your main zone and the dummy zone (so Outside Boundary Condition = Surface).

In the dummy zone, keep actual environmental conditions or a controlled schedule to approximate the desired temperature.

Model the wall as a normal exterior wall with Outdoors and use schedules to control window temperatures indirectly

Use constructions and thermal mass plus schedules if your goal is controlling heat transfer rather than strictly enforcing a single outside surface temperature.

---

Or am I misreading things?

best
-trevor

[edpmay]

Hey Trevor!

Weird. Maybe they removed it? In the 8.2 docs it definitely shows a window hosted in a surface with an OSC BC:

BuildingSurface:Detailed,
    Zn001:Roof001,           !- Name
    Roof,                    !- Surface Type
    ROOF31,                  !- Construction Name
    ZONE ONE,                !- Zone Name
    OtherSideCoefficients,   !- Outside Boundary Condition <---------
    Zn001:Roof001:OSC,       !- Outside Boundary Condition Object
    NoSun,                   !- Sun Exposure
    NoWind,                  !- Wind Exposure
    0,                       !- View Factor to Ground
    4,                       !- Number of Vertices
    0.000000,15.24000,4.572,  !- X,Y,Z ==> Vertex 1 {m}
    0.000000,0.000000,4.572,  !- X,Y,Z ==> Vertex 2 {m}
    15.24000,0.000000,4.572,  !- X,Y,Z ==> Vertex 3 {m}
    15.24000,15.24000,4.572;  !- X,Y,Z ==> Vertex 4 {m}

  FenestrationSurface:Detailed,
    panel002,                !- Name
    Door,                    !- Surface Type
    PanelConst,              !- Construction Name
    Zn001:Roof001,           !- Building Surface Name <------------
    ,                        !- Outside Boundary Condition Object
    autocalculate,           !- View Factor to Ground
    ,                        !- Shading Control Name
    ,                        !- Frame and Divider Name
    1,                       !- Multiplier
    4,                       !- Number of Vertices
    3,2,4.572,  !- X,Y,Z ==> Vertex 1 {m}
    3,3,4.572,  !- X,Y,Z ==> Vertex 2 {m}
    4,3,4.572,  !- X,Y,Z ==> Vertex 3 {m}
    4,2,4.572;  !- X,Y,Z ==> Vertex 4 {m}

maybe that isn’t allowed in the new versions for some reason?

@edpmay

[TrevorFedyna]

@edpmay I found this prompt to yield interesting results.
It seems windows/glassdoors are an issue but opaque doors may be a non-issue
I bet @chris would know what the deal is here, I hope for his input!
best
-t

[chris]

Hey @edpmay and @TrevorFedyna ,

Sorry for the late response here. My understanding when I put the HB Other Side Temperature component together along with it’s corresponding class in honeybee-energy is that E+ did not allow it to be assigned to Faces with Apertures. I would just expect the E+ object to have properties for “Sun Exposure” if it were possible to put a transparent Aperture or Glass Door on a Face that has that boundary condition (which it does not).

But the example that you showed, @edpmay, makes sense and what chatgpt suggested sounds plausible. I guess it can probably be assigned to Faces that only have opaque doors. Is this ability to assign the Other Side Coefficients to Faces with opaque doors something that you need for your workflows, @edpmay ?

[edpmay]

Hey @chris, @TrevorFedyna .

Thanks for following up. That makes sense. Though I don’t think I see why E+ can’t have glazed openings to an attached space, but oh well

For the doors: actually yes, this would be very useful if it was possible. The specific use-case was actual related to supporting the WUFI-Passive export. In WUFI-Passive they have a language of ‘attached zones’ (garage, loggia, sunroom, ect…) which you apply a reduction factor to. So any surface with exposure to those attached zones have reduced heat loss.

In order to support this feature (which is being asked for a recent certification project) I was trying to add a new HB-PH ‘Attached Zone’ BC and subclassing from OtherSideTemperature since this seemed like the logical E+ match.

There are a few possible workarounds I can explore, so this is not critical, but if there is ever an option to support hosting opaque door apertures on OST BC surfaces, that would be a useful feature for our WUFI-Passive conversion work.

thanks!!
@edpmay

[TrevorFedyna]

I mean in the docs they have detailed apertures on OSC bc surfaces:
To me it looks like the actual add aperture to surface component only allows surface or outdoors bc. I haven’t had time to test it with allowance to othersideecoefficience but I think that might send smoothly. Busy weekend ive been meaning to test it will hopefully soon
best
-trev

[chris]

Ok. So I did a quick hack and I don’t know the source of your claim, @TrevorFedyna , but the 25.1 version of EnergyPlus that we are currently using definitely does not support using Other Side Coefficients with Windows:

If I change it to an opaque Door, then I can get EnergyPlus to succeed:

… but, if I change the door to be a glass door, it fails again:

So the original hypothesis was correct that only opaque doors can use the OtherSideCoefficeints object in E+. Apertures cannot use then and glass doors cannot use them. So I am not going to remove the current checks that help users prevent these cases before they become a problem in E+ simulation.

Refactoring honeybee-core to permit OtherSideTemperature boundary conditions for opaque doors is going to take some effort, @edpmay . And, if I am being realistic, the first iteration of it may have some bugs just because there are so many places in the core libraries that rely on the boundary conditions being used in a specific way. But, if you open an issue on the honeybee-core GitHub, I can get to it eventually

[TrevorFedyna]

I could have sworn I saw it in the documentation somewhere but it looks like that was not the case