Calculate overall fenestration product U-factor, SHGC, and VT without running simulation

[rd2]

Enhancement Request

Provide SDK users with functionality to access overall fenestration U-factor, SHGC, and VT ... similar to this (open) new feature EnergyPlus request).

Detailed Description

When linking fenestrated subsurfaces (e.g. GlassDoor, FixedWindow) with frame & divider (F&D) objects, there is no obvious solution for users to retrieve the overall fenestration U-factor (as well as SHGC & VT), similar to NFRC calculations. A given building design may have e.g. 3 fenestrated subsurface multilayered constructions, and 17 unique window sizes. The generic nature of F&D objects (i.e. a single F&D object may be reused for multiple fenestrated subsurfaces with unique geometries) offers OpenStudio/EnergyPlus users a very useful (automated) solution to generate a wide range of subsurface-specific properties (great). But in the end, users cannot retrieve the resulting NRFC-like aggregate metrics like overall U-factors. This is becoming an issue for pre-simulation input validation (and/or post-simulation output validation) for code compliance purposes in cold climates e.g., recent codes, upcoming revisions (currently in development).

Possible Implementation

2 options:

1. (preferred) Implement the NFRC/LBNL Window calculations in the OpenStudio SDK to generate subsurface-specific U-factors (standard winter conditions), SHGC (standard summer conditions) ... and VT (less of a priority). A first prototype could be an OpenStudio Measure (or a common gem).
2. (quick fix) If users have F&D inputs (LBNL Window) for a given fenestration product, they likely already have on hand NFRC U-factors for standard winter conditions. Allow SDK users to set a fenestrated subsurface uFactor as a placeholder for pre-simulation input validation (currently not allowed). This would not provide the desired flexibility described above, but it would be better than nothing. EDIT: straightforward to implement with AdditionalProperties as per @shorowit 's suggestion (see below).

Both options would have no bearing on EnergyPlus inputs and/or simulation results.

[macumber]

This would be a good potential first example of linking OpenStudio to either the EnergyPlus C libraries or linking to Windows-CalcEngine directly. The calculations for window properties are too detailed to reproduce IMHO, it would be better to just link to the same libraries that EnergyPlus uses directly.

[shorowit]

@rd2 Is your "quick fix" simply the desire to tag the U-factor on a subsurface? If so, you can use the additionalProperties object for that.

subsurface.additionalProperties.setFeature("uFactor", Float(ufactor))
puts subsurface.additionalProperties.getFeatureAsDouble("uFactor").get

[rd2]

@shorowit : true!

[rd2]

As per @shorowit 's suggestion, option 2 (the quick fix) is easy to set up with AdditionalProperties. Implemented here, and tested here. Thanks!

[jmarrec]

I'm not sure I'm following the intent correctly. But it seems you can just run a single day of simulation or whatnot and get it from E+ SQL file. Surface::uFactor() can be used to do that SQL query for you.

[rd2]

It doesn't look like E+ is there yet (soonish? 9.6?).

[jmarrec]

Ok, for assembly, E+ has yet to report that. But the point remains the same. If E+ can do that for you currently, then do a run and retrieve the value. Once NREL/EnergyPlus#8740 is merged in we can add a helper function to query the Sql, sure.

---

Linking to the E+ C API is a nice idea, but the C API is currently very shallow and definitely doesn't include this type of functions. It exposes only functions for EMS-like features and some simple others like Psychrometric ones (where you pass in a couple of doubles and that's it, eg https://github.com/NREL/EnergyPlus/blob/55c844eb1883650f490889137692aab8b58fd103/src/EnergyPlus/api/func.cc#L163-L170)

These specific calculations require the internal state of E+ to be initialized by (a ton of) routines in a specific order so that the data structures are populated accordingly for the calculation to succeed. These routines also often don't just do the specific bit you are interested in but more than that, so you must initialize a bunch of other stuff ("globals") if you want to run a specific routine and not have it crash. Trust me on that, this is why writing unit tests for E+ is really really painful.

Anyways, we can't really just pass in a few numbers and get something out of it, so to me it looks like a big no go right now.

[macumber]

I added #4403 to request the Sql helpers after NREL/EnergyPlus#8740 is merged

[jmarrec]

Can I close this one to be superseded by #4403 then?

[macumber]

I think #4403 is a short term fix but I think this issue is still valid as a long term feature request to actually do the calculations without having to run a simulation (Denis's preferred solution of "Implement the NFRC/LBNL Window calculations in the OpenStudio SDK to generate subsurface-specific U-factors"). We could retitle the issue to "Calculate overall fenestration product U-factor, SHGC, and VT without running simulation" to be more clear, @rd2 what do you think?

[rd2]

Agree with @macumber 's suggestion.

[macumber]

It sounds like these calculations would not be a good fit for the E+ API so it is probably best to just link OS with https://github.com/LBNL-ETA/Windows-CalcEngine directly

[jmarrec]

Note that it'd require building Windows-CalcEngine as part of the build process. libWindows-CalcEngine.a is 5MB is release and 1484 MB in Debug.

I personally think that this is more trouble that the benefits it brings, but I'll defer to @tijcolem on this.

[tijcolem]

This just popped up during iteration meeting. I am fine keeping this open as longer term feature request. I don't know what's involved in using the Window-calcengine. We'd need to make sure this would be supported cross-platform via conan, but it sounds like it would.