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
-
@chriswmackey suggested, that they would automatically change the BC from
Ground
toOutdoors
, if there is an aperture in the surface - this would prevent the fatal error from occurring. -
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 aGround level
parameter in Pollination would be handy, where you can specify that what is the ground plane’s elevation compared toRhino World Z=0
, below which external face BCs should be considered asGround
, otherwise it’sOutdoors
. But then you would still have to change some of them anyway, as the terrain sloping is not always so easy to specify. -
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 assignedOutdoors
). 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 fewBooleanDifference
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.