Extending HB-E Boundary Conditions?

[ed-p-may]

Hi, @chriswmackey , @mostaphaRoudsari ,

I have a question related to extending HB-Energy Boundary Condition objects:

I am trying to look at what it would take to implement a 'Kiva' style Foundation BC within our Honeybee-REVIVE extension. In order to add this new BC, the first step is to create a new custom BC. This part I understand
based on how you did it for "Adiabatic" and "OtherSideTemperature" already, and it appears that I am able to easily extend hb-energy with a new "Foundation" BC object. I can set HB-face BCs to this new type, and it writes out to IDF as expected (Foundation, !- Outside Boundary Condition). So that part is great.

However: in addition to setting the BC name to "Foundation", I also need to set the Outside Boundary Condition Object to be a reference to a new Kivy object (which will be appended to the IDF elsewhere....).

Reviewing the honeybee-energy code, I think (maybe) I understand where the BC IDF text is being generated, and based on my reading here it appears that there is no way to add this new reference? It seems that only the special types "Surface" and "OtherSideTemperature" add the bc-object text to the idf string?

from honeybee_energy.writer.face_to_idf

. . . 
# select the correct boundary condition
bc_name, append_txt = face.boundary_condition.name, None
if isinstance(face.boundary_condition, Surface):
    face_bc_obj = face.boundary_condition.boundary_condition_object
elif face.boundary_condition.name == 'OtherSideTemperature':
    face_bc_obj = '{}_OtherTemp'.format(face.identifier)
    append_txt = face.boundary_condition.to_idf(face_bc_obj)
    bc_name = 'OtherSideCoefficients'
else:
    face_bc_obj = ''
. . . 

So given the above, do you think it is accurate to say it is not possible to have a new custom BC add text to the "Outside Boundary Condition Object" line? Perhaps I am missing something though?

I suppose that I could subclass 'Surface' with my new BC and that would get past the isinstance check?

But I wonder if the above could be made a bit more extensible and allow any BC that has a .boundary_condition attribute to write itself to the IDF?

Perhaps something like below, instead of checking the nominal type of Surface, just check for the bc attribute?

. . . 
# select the correct boundary condition
bc_name, append_txt = face.boundary_condition.name, None
if face.boundary_condition.name == 'OtherSideTemperature':
    face_bc_obj = '{}_OtherTemp'.format(face.identifier)
    append_txt = face.boundary_condition.to_idf(face_bc_obj)
    bc_name = 'OtherSideCoefficients'
elif hasattr(face.boundary_condition, "boundary_condition_object"):  #<----
   face_bc_obj = face.boundary_condition.boundary_condition_object   #<-----
else:
    face_bc_obj = ''
. . . 

any thoughts are much appreciated as always,
@ed-p-may

[chriswmackey]

Hey @ed-p-may ,

You should be thinking of KIVA boundary conditions this as something that goes completely in honeybee-energy. Because it's native E+ functionality, it should live in this package and not an extension.

With that in mind, what stops you from treating this like a Surface boundary condition? Do you need to reference lots of different types of "Outside Boundary Condition Objects?" Or is it just one that gets used everywhere?

[ed-p-may]

Hi @chriswmackey , interesting. I'd be all for adding it as a first-class HBE object. Happy to help put that together.

From what I understand (still learning how KIVA works....) a very basic working implementation would include 3 elements in the IDF:

1) A new "Foundation" object:

This gets referenced by the various building-surfaces in the model which are part of the KIVA set. A model can have more than one 'set', and so more than one "Foundation" object present. But it needs at least one.

FOUNDATION:KIVA,
  My Kiva Foundation,      !- Name
  ,                        !- Initial Indoor Air Temperature {C}
  ,                        !- Interior Horizontal Insulation Material Name
  0,                       !- Interior Horizontal Insulation Depth {m}
  ,                        !- Interior Horizontal Insulation Width {m}
  ,                        !- Interior Vertical Insulation Material Name
  ,                        !- Interior Vertical Insulation Depth {m}
  ,                        !- Exterior Horizontal Insulation Material Name
  ,                        !- Exterior Horizontal Insulation Depth {m}
  0,                       !- Exterior Horizontal Insulation Width {m}
  EPS 2in,                 !- Exterior Vertical Insulation Material Name #<--- THIS MATERIAL ALSO NEEDS TO BE ADDED
  0.0003048,               !- Exterior Vertical Insulation Depth {m}
  0.2,                     !- Wall Height Above Grade {m}
  0,                       !- Wall Depth Below Slab {m}
  ,                        !- Footing Wall Construction Name
  ,                        !- Footing Material Name
  0.4;                     !- Footing Depth {m}

2) A new "Properties" object:

Each "Foundation" object needs one Property object.

SURFACEPROPERTY:EXPOSEDFOUNDATIONPERIMETER,
  Basement,                !- Surface Name
  TotalExposedPerimeter,   !- Exposed Perimeter Calculation Method
  12.192,                  !- Total Exposed Perimeter {m}
  1,                       !- Exposed Perimeter Fraction {dimensionless}
  Yes;                     !- Surface Segment 1 Exposed

3) Setting the Building Surface BC values:

This has two parts:

• Set the "Outside Boundary Condition" to "Foundation"
• Set the "Outside Boundary Condition Object" to reference the KIVA-Foundation object

So that looks roughly like:

BuildingSurface:Detailed,
  Slab,                    !- Name
  Floor,                   !- Surface Type
  Exterior Slab UnIns,     !- Construction Name
  WholeHouse,              !- Zone Name
  ,                        !- Space Name
  Foundation,              !- Outside Boundary Condition #<------- HERE. 'Surface' > 'Foundation'
  My Kiva Foundation,      !- Outside Boundary Condition Object #<------ HERE
  NoSun,                   !- Sun Exposure
  NoWind,                  !- Wind Exposure
  0,                       !- View Factor to Ground
  4,                       !- Number of Vertices
  8.1534,11.6713,0,  !- X,Y,Z ==> Vertex 1 {m}
  8.153399999999,8.013700000009,0,  !- X,Y,Z ==> Vertex 2 {m}
  0,8.013700000009,0,  !- X,Y,Z ==> Vertex 3 {m}
  0,11.6713,0;  !- X,Y,Z ==> Vertex 4 {m}

---

So, given that, the existing "Surface" BC can almost work, except that it has to yield a boundarycondition.name of "Foundation" when writing to the IDF, rather than "Surface"? So I think HBE would need a whole new type for that, since the name is set to always be the type?

[chriswmackey]

Thanks for clarifying, @ed-p-may .

I am tempted to wrap all of the attributes of the foundation and the properties object into a singe new GroundKIVA boundary condition object that gets assigned to honeybee Faces. This would basically mean that each Floor face with a GroundKIVA boundary condition would only ever have one Foundation object and one SURFACEPROPERTY:EXPOSEDFOUNDATIONPERIMETER object. I'm guessing there are other types of surface property objects here, no? Are basement floors modeled the same way as a slab on grade?

In any event, I just know that everything is going to be much easier to implement on the honeybee side if everything is wrapped into a single object that can be assigned to a Face. Do you think users will find it acceptable that they may get a lot of Foundation objects in their IDF because each Floor face will get a separate foundation object?

[ed-p-may]

@chriswmackey Personally, I think it is totally fine having unique FOUNDATION:KIVA instances for each floor surface in a Honeybee-Room, and to merge the FOUNDATION:KIVA and the SURFACEPROPERTY:EXPOSEDFOUNDATIONPERIMETER together into a single new Honeybee-Energy object.

One thing to note is that (from what I understand, just reading their docs and experimenting a bit) it appears that the floor surfaces and the wall surfaces need to reference the same FOUNDATION:KIVA object. So that new Honeybee Object would need to be reference-able from multiple surfaces, I suppose similar to how constructions are handled.

From what I gather, I think that the basic KIVA IDF structure is something like this:

Where:

1. There is a new FOUNDATION:KIVA object
2. The Floor(s) and the Walls reference this object in their Outside Boundary Condition Object
3. There is a new SURFACEPROPERTY:EXPOSEDFOUNDATIONPERIMETER
4. This references just the Floor surface

Do you think that changes how we would anticipate approaching these items?

[chriswmackey]

Thanks @ed-p-may ,

This complicates the situation quite a lot:

One thing to note is that (from what I understand, just reading their docs and experimenting a bit) it appears that the floor surfaces and the wall surfaces need to reference the same FOUNDATION:KIVA object. So that new Honeybee Object would need to be reference-able from multiple surfaces

I'll need some time to think about this as I have not implemented a boundary condition yet that requires referencing another object. It messes with how we set up boundary conditions to live underneath honeybee-core Faces and to be serialized with those Faces, deleted if those Faces are deleted, etc.

Probably, the way that it will have to be implemented is with duplicate foundation specifications under each Face and I'll need to have the model serialization routine find all of these foundations and consolidate them into a unique set.

Given all of the complexity here, would you mind if I took care of this one after thinking about it a little more? Maybe I'll try to do both this and these C/F-factor ground boundary conditions at the same time as this one.

[ed-p-may]

For sure! There is no time pressure on our end. We have a workaround that we can apply internally for now and no specific time-table on when we are trying to make theHoneybee-REVIVE package available to users. From our testing so far, it looks like this mainly matters for un- or poorly-insulated ground contact surfaces (which, of course, are a big part of 'retrofit' modeling though...).

Although: I suppose a minimal implementation would be to apply the KIVA Foundation only to floor surfaces and just omit walls? In that case, each BC could still be unique to the single floor surface? From a quick test, this appears to show almost the same result as if it is applied to the walls and the floor? I suppose it depends on the extent of the subgrade walls... but I would imagine that for most cases this would be good enough?

(Note: the above is showing a 'power-outage' scenario where the mech switches 'off' for a week in winter)

model attached:
testing_kiva.gh.zip

[chriswmackey]

Thanks, @ed-p-may .

Even if the results are close, I would prefer to do this right the first time rather than assemble something quick that I then have to change after others start using it and building on top of it. I think I can get the use of references to foundation objects to work. Now that I think about it more, maybe the Foundation should be a special type of construction object that, when it's assigned to Honeybee Faces with a Ground boundary condition, triggers the ground to be modeled with KIVA instead of the usual method.

Let me think about it more and get back to this.