External surface boundary conditions below 0 Z coordinates

[furtonb]

Hi,

I’m posting a part of a discussion that we had with the Pollination team regarding one of our problematic models:

Context
If there is a heavily sloping terrain, it could occur, that the 0,00m level is not at the bottom of the building. As we tend to model a lot according to 2D DWGs (Archicad is not getting any love), we usually put these drawings to the corresponding height (where Z = finished floor level, that is specified on the section) onto a horizontal CPlane. So it happens, that some floors get to the negative Z range for lower levels. Without breaking too much NDA, there is a blurry section from a recent plan, to give you an idea:

As a result, there are surfaces, that will be considered adjacent to the ground, although they are external surfaces having doors/windows/skylights to them, resulting in fatal EnergyPlus errors - as faces that have apertures cannot have Ground boundary condition attached to them.

The problem is, that it looks like EnergyPlus has no idea about about the site conditions, assigning boundary conditions based on oversimplified rules: a surface having all it's vertices' Z coordinate < 0 → Ground BC, not looking at the context, the program, etc.

Possible solutions

1. @chriswmackey suggested, that they would automatically change the BC from Ground to Outdoors, if there is an aperture in the surface - this would prevent the fatal error from occurring.

2. Is there a Ground level parameter in EnergyPlus to offset it from the default 0? I searched for it in the reference guide (not too extensively, I admit), but I can’t recall being able to change this. Maybe having a Ground level parameter in Pollination would be handy, where you can specify that what is the ground plane’s elevation compared to Rhino World Z=0, below which external face BCs should be considered as Ground, otherwise it’s Outdoors. But then you would still have to change some of them anyway, as the terrain sloping is not always so easy to specify.

3. You could actually model the site (could be imported from the IFC provided) and solve adjacencies between the terrain and the bldg model – then change the BC for the building’s adjacent faces to terrain to Ground (the rest should be left alone and assigned Outdoors). Maybe introducing a “Terrain” class to Pollination is the way to go? I believe in most cases it would be an accurate solution after a few BooleanDifference operations.

What do you guys think about it? Have you encountered such buildings, if so, what was your solution?
Above a certain scale splitting faces and manually setting BCs are becoming error prone and tedious.

[chriswmackey]

Hi @furtonb ,

I think you might be putting too much blame on EnergyPlus since the ground plane is something that exists only within the Pollination Rhino and LBT Grasshopper plugin. There’s no concept of ground plane in EnergyPlus and, by the time that the model gets to E+, every Face has a separate boundary condition definition on it.

Both the Pollination Rhino and LBT Grasshopper plugins will assign a Ground boundary condition to Faces that are below the Rhino origin by default. To override this default behavior in the Rhino plugin, you can select individual Faces and change their boundary condition by going to the “Edit Properties” menu:

I’m sure that there are other good workflows for changing the boundary condition of Faces in Rhino Plugin and @mingbo can point you towards them.

In the LBT-Grasshopper plugin, there’s a component called HB Custom Ground, which can be used to assign Ground boundary conditions to Rooms using a terrain surface like so:

I just added a reset_ option to this component, which is particularly useful for your case here where you want the terrain surface to essentially override the default ground plane at the Rhino origin (resetting all Faces above the terrain surface to have an Outdoor boundary condition):

fix(create): Add an option to reset BCs using ground surface

You can get the updated component with the LB Versioner in a hour or so and I hope that gives you what you need to quickly fix your model here.

[furtonb]

Thanks, @chriswmackey !

EnergyPlus is a wonderful engine, but I’m far from mastering it - hence the false assumption from my side. Thanks for the clarification!

I have never noticed the HB Custom Ground component, that looks exactly what I’m after.
I’ll try it later, as I’ve already fixed the affected faces with the Pollination method you described above.