Can OtherSideTemperature BC Allow Apertures?

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:

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



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

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:

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

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

:pushpin: 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

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

@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