Revise Implementation of Surface-Films for OpaqueMaterials?

[ed-p-may]

Hi @chriswmackey ,

I wanted to ask a question and make a suggestion regarding surface films for OpaqueConstructions and see what you think?

---

Background: in order to complete the Honeybee-PH plugin, one item I would like to include would be the option to use ISO-6946 surface films for opaque assemblies such as walls, roofs and floors. These are the ones we are required to use for PH-modeling. I was going to build a simple component as part of the Honeybee-PH plugin to allow users to add that data, but I am wondering if modifying the Honeybee-Energy would be a better method that would be useful for many other applications that just PH-modeling.

I notice that the current implementation of OpaqueConstruction already allows for two methods regarding surface films, the ISO-10292 for simple u-factors, and the ISO-15099 for detailed u-factors.

---

Question: I am not familiar with ISO-10292, but are we sure that it can be used for opaque assemblies? It seems to indicate from the title that it is only for Glazing?

---

Suggestion: While the current implementation is great, and seems to work well, I think there are at least a few cases where users would want the option of specifying an alternative protocol to model to. For instance, for many applications, the ISO-6946 would be the required protocol, and then in the US and Cananda, the ASHRAE protocol would be the recommend/required protocol for most models I think, right?

The ISO-6946 specifies surface films using an 'orientation' and 'exposure' basis:

And the ASHRAE HoF, Chapter 26 uses a similar rubric, but with slightly different values:

---

So, I was thinking that it would be important for users to be able to specify which of these protocols to use. Obviously having the simple default ISO-10292/15099 for most users is great, but if you are modeling to show compliance with building code or other framework like Passive House, you would be required to use either the ISO or ASHRAE values instead (in the cases I am familiar with at least).

My initial instinct is that we could add a simple 'flag' of some sort to the Construction object to allow for the user to specify the type of calculation to use? Something like:

---

But: I wanted to see what you thought? Obviously I'm happy to add in the code / logic for something like this and send along a PR, if you think its a good idea. Alternatively I can keep it all inside the Honeybee-PH plugin and then there will just be some small difference between the HB-E U-factors and the PH U-factors, which is fine I think.

Of course: these values are super small and won't make much impact on well insulated buildings - but it has popped up as an issue during model-reviews, just in terms of consistency and standardization / input checking.

Let me know what you think though.
Thanks!
-Ed @PH-Tools

[chriswmackey]

Hey @PH-Tools ,

There's a lot to unpack here but, starting with the most important, I'm ok with having separate in_simple() methods for Opaque vs. Window constructions. It seems that the ISO-6946 standard isn't robust enough to apply to opaque materials that have an emissivity other than 0.9 but, if you wanted to have the in_simple() method for OpaqueConstructions return the horizontal value of the ISO-6946 standard only when the OpaqueConstruction.inside_emissivity == 0.9, I'd be alright with that.

I was under the impression that the values in the ASHRAE HOF table aligned with the ISO-15099 standard for detailed u-factors but, if they don't, then adding a separate method on the ConstructionBase class for in_ashrae(orientation='horizontal') seems fine. And it's only limited to those 5 orientations. You could do the same for OpaqueConstruction.in_iso_6946(orientation='horizontal') if you wanted to give a means of accessing the other orientations.

But I feel pretty strongly that the film coefficient standard is not a property of the OpaqueConstruction class as your image of Grasshopper components implies. If it was really desired, we could probably add an input to the HB Deconstruct Construction component that allowed you to select the standard used for the U-factor calculation.

[ed-p-may]

Hey @chriswmackey , sorry for the delay getting back to this:

---

I was under the impression that the values in the ASHRAE HOF table aligned with the ISO-15099 standard for detailed u-factors

Interesting: they might? - But I'm not familiar with 15099 myself. But they (ASHRAE values) are definitely different than ISO-6946 which is the one I'm more familiar with and the one that we have to comply with when doing international projects. In both ASHRAE and 6946 though (as far as I know at least) the surface films are supposed to vary depending on the direction of heat flow (ie: interior film horizontal flow through a wall should be R-0.12 while upward flow through a ceiling should be R-0.11, etc..)

---

I'm ok with having separate in_simple() methods for Opaque vs. Window constructions.

I think the current implementation using in_h_simple() for opaque, and the separate in_h() for windows makes sense: the proposed change here is only with regard to opaque constructions, not windows. So yes: I'm proposing keeping those exiting methods separate, and just adding in a new one for ASHRAE and another for ISO.

---

But I feel pretty strongly that the film coefficient standard is not a property of the OpaqueConstruction

I think they are already are though - aren't they? Or am I misunderstanding the way those are being used by the Constructions? construction._base.ConstructionBase includes this method (so not a python property technically, but effectively it is, right?):

def out_h_simple(self):
    """Get the simple outdoor heat transfer coefficient according to ISO 10292.

    This is used for all opaque R-factor calculations.
    """
    return 23

Maybe I didn't understand what you meant by that comment though? (Are you referring to the GH component 'OpaqueConstruction', or to the HB python class 'OpaqueConstruction'?)
I'm suggesting to add another method (call it: out_h_ iso_6946) to _base._ConstructionBase alongside the already existing out_h_simple. Then when r_factor is called, instead of automatically using out_h_simple, there is some logic / option to allow the use of the new out_h_iso_6946 method, if specified by the user. So roughly something like:

def out_h_iso_6946(self):
    return 1/0.04 # (25)

def in_h_iso_6946(self, heat_flow_direction="Horizontal"):
    # As per ISO-6946 Table 7
    # Actual implementation nicer, but something like this:
    if heat_flow_direction == "Horizontal":
        return 0.13
    elif heat_flow_direction == "Upwards":
        return 0.10
    elif heat_flow_direction == "Downwards":
        return 0.17
    else:
        return 0.13

@property
def r_factor(self):
    if #flag:
        _ext_r = 1/self.out_h_iso_6946()
        _ext_r = 1/self.in_h_iso_6946()
    else:
        _ext_r = 1 / self.out_h_simple()  # exterior heat transfer coefficient in m2-K/W
        _int_r = 1 / self.in_h_simple()  # interior film
  
return self.r_value + _ext_r + _int_r

Everything should always default to the current values, so if the user takes no action or does not specify, they always get the 'simple' values. But they then have an option to add further specificity to the calculation method / values to use, if they need/want.

Let me know if I misunderstood your last comment though? But if you are ok with me giving it a try and adding in_ashrae(orientation='horizontal') and an in_iso_6946(orientation='horizontal') (or something like that) then I'll mock up an implementation and you can see if you like it.

[chriswmackey]

Hey @PH-Tools ,

Sorry for the late response here. I am mostly ok with the code you proposed but I think it should be implemented more like this:

def out_h_iso_6946(self):
    return 1/0.04 # (25)

def in_h_iso_6946(self, heat_flow_direction="Horizontal"):
    # As per ISO-6946 Table 7
    # Actual implementation nicer, but something like this:
    if heat_flow_direction == "Horizontal":
        return 0.13
    elif heat_flow_direction == "Upwards":
        return 0.10
    elif heat_flow_direction == "Downwards":
        return 0.17
    else:
        return 0.13

def r_factor_iso_6946(self, heat_flow_direction="Horizontal"):
    _ext_r = 1 / self.out_h_iso_6946()
    _int_r = 1 / self.in_h_iso_6946(heat_flow_direction)
    return self.r_value + _ext_r + _int_r

This ISO 6946 R-value is something that has it's own restrictions that are distinct from the other models for film coefficients, which either do not account for the orientation of the construction (in the case of the simple coefficients), or they account for all possible orientations of the construction in the case of the R-values computed with the temperature_profile method. So it seems clearest to expose this limitation of three construction orientations on the method that returns this particular type of R-value.

If you want to send a PR with the code above, I would be happy to merge it (assuming that you add some good docstrings). From that point, we can decide the best way to expose it on Grasshopper components (eg. on the component that returns the R-value of a construction.