"Surface Window Net Heat Transfer Energy" does not account for all heat transfer across the windows

[chriswmackey]

Issue overview

After not finding an explanation on Unmethours, I'm fairly confident that there is either something is incorrect in the E+ docs or there is a bug related to the following E+ output:

Surface Window Net Heat Transfer Energy

This output is consistently missing some amount of energy transferred out of the windows in order to account for the complete heat flow across the window.

Details

The easiest way to replicate and understand the issue is to build a model where all of the heat flow in and out of the zone should be across the windows. That is, a single-zone model without any HVAC, internal loads, or infiltration. If the model has an adiabatic floor and ceiling and walls with 100% glazing ratio, then the Surface Window Net Heat Transfer Energy should account for all of the zone heat flow in the model. So summing the values of Surface Window Net Heat Transfer Energy for every month should give something close to zero if EnergyPlus is respecting the first law of thermodynamics and the energy in = energy out when the temperature of the zone is not significantly changing. Here is an IDF for one such model:
https://drive.google.com/file/d/1c_RsW1Jo_dcOAwDu1XZZnQcuwz1wjTwO/view?usp=sharing

And here's a screenshot of what it looks like:

When we look at the monthly values of Surface Window Net Heat Transfer Energy for this model, we consistently get positive values, which are a significant fraction of the overall heat balance of the model and indicate that some energy that's flowing out of the windows is not accounted for in the Surface Window Net Heat Transfer Energy. Here are the monthly totals in kWh when running the IDF above using the Boston EPW file from DoE:

• Jan: 499
• Feb: 713
• Mar: 787
• Apr: 500
• May: 903
• Jun: 809
• Jul: 750
• Aug: 699
• Sep: 547
• Oct: 542
• Nov: 344
• Dec: 523

And you can visualize the overall heat balance of the model in the flowing chart where "Solar" is the Zone Windows Total Transmitted Solar Radiation Energy, "Window Loss" is the Surface Window Net Heat Transfer Energy minus the "Solar" and "Unidentified Heat Loss" is the remaining term that would be needed to make the monthly results sum to zero and respect the first law of thermodynamics.

It is important to note that, while the IDF example I uploaded is the simplest way to see the issue, I consistently get the the Surface Window Net Heat Transfer Energy being more positive than it should be. This is true no matter which EPW file I use or whether the zone is conditioned. As long as the glazing ratio of the model is high enough, this imbalance becomes noticeable and it doesn't go away with a higher simulation timestep or more advanced solar distribution calculations.

I have also noticed that combining the following E+ outputs gives me something consistently positive, which makes me think that one of them might not be reporting everything that it should:

• Surface Window Transmitted Solar Radiation Rate
• Surface Window Inside Face Glazing Zone Convection Heat Gain Rate
• Surface Window Inside Face Glazing Net Infrared Heat Transfer Rate
• Surface Window Shortwave from Zone Back Out Window Heat Transfer Rate

Note that I subtract the Surface Window Shortwave from Zone Back Out Window Heat Transfer Rate since it comes out of the simulation as a positive term while the other 3 have the appropriate sign.

It's also possible that there's just another term that I should be accounting for outside of these 4 that would make everything balanced. However, I have been unable to come up with what I'm missing after racking my brain for a week and no one has had any suggestions on Unmethours. Faced with the current situation, I have just started using a fudge factor to get rid of the "Unidentified Heat Loss" in the load balances I create from EnergyPlus and I'm inclined to think this is a bug. Or perhaps the E+ docs are missing some important details (eg. maybe the Surface Window Shortwave from Zone Back Out Window Heat Transfer Rate does not include all shortwave solar that makes it out though each window).

Some clarification on this would be much appreciated.

Checklist

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• Defect file added (list location of defect file here)
• Ticket added to Pivotal for defect (development team task)
• Pull request created (the pull request will have additional tasks related to reviewing changes that fix this defect)

[chriswmackey]

I'm just wondering if anyone else has had the chance to read this or has a possible explanation for why the outputs of the window calculation do not seem to be in agreement with energy conservation.

Could this all just be a consequence of the transient calculation of EnergyPlus? For example, maybe there's some factor that's deleting some amount of energy just to help keep the transient calculation stable?

That explanation would make sense to me but it would just be good to have some confirmation that what I am seeing here is a part of the intentional design of E+ and not a bug.

[chriswmackey]

Given the silence here, I'm just going to advise people that the Surface Window Net Heat Transfer Energy EnergyPlus output is missing something and that they should multiply it by some fudge factor of 6% to make things balanced. I still don't know what this missing thing is but I would assume that there would be more concern from others here if the explanation was that the energy balance equations of E+ were wrong. So I'm just going to assume the problem is with the output.

[mjwitte]

This is a tangled web that includes some side calculations that are only used to generate certain output variables.

1. Stepping back from the heat gain, I tried to balance all of the solar in the zone, looking at these output variables:

Zone Windows Total Transmitted Solar Radiation Energy
Surface Window Shortwave from Zone Back Out Window Heat Transfer Rate
Surface Inside Face Initial Transmitted Diffuse Transmitted Out Window Solar Radiation Rate
Surface Inside Face Solar Radiation Heat Gain Energy (opaque surfaces)

This was close, but off by a few %.
Turns out that the two "Out Window" rates do correctly report what goes all the way out the window to the outdoors by using the window diffuse transmittance. But part of the solar that leaves the zone balance is absorbed in the window glass (in addition to what's absorbed by the initial incoming solar). So, to balance these they need to be adjusted to SolarOut/DiffTransmittance*(1-DiffReflectance).

2. "Surface Window Net Heat Transfer Energy" is accounting for "Surface Window Shortwave from Zone Back Out Window Heat Transfer Rate" but it should also be subtracting "Surface Inside Face Initial Transmitted Diffuse Transmitted Out Window Solar Radiation Rate".
3. Plus, because "Surface Window Net Heat Transfer Energy" is balanced at the inside face of the window (using convection and radiation terms), this should also be subtracting the adjusted SolarOut values.

Work is in progress to correct these, but it won't make it in for v24.1

[mjwitte]

From #10444 (comment)

Then I tried the same with FullInteriorAndExterior, and the imbalance ranges from 0.8 to 6%, highest in the winter months. Looks like we need yet another window variable to track beam solar that leaves out a window.

In SolarShading::CalcInteriorSolarDistribution, state.dataSurface->SurfWinBmSolTransThruIntWinRep is calculated.
Array1D<Real64> SurfWinBmSolTransThruIntWinRep; // Beam solar transmitted through interior window [W]
This is used for output variables "Surface Window Transmitted Beam Solar Radiation Rate" and "Surface Window Transmitted Beam Solar Radiation Energy" for interior window surfaces.

The amount of interior beam incident on each surface is calculated and saved state.dataHeatBal->SurfBmIncInsSurfAmountRep

    Array1D<Real64> SurfBmIncInsSurfIntensRep;          // Beam sol irrad from ext wins on inside of surface (W/m2)
    Array1D<Real64> SurfBmIncInsSurfAmountRep;          // Beam sol amount from ext wins incident on inside of surface (W)
    Array1D<Real64> SurfIntBmIncInsSurfIntensRep;       // Beam sol irrad from int wins on inside of surface (W/m2)
    Array1D<Real64> SurfIntBmIncInsSurfAmountRep;       // Beam sol amount from int wins incident on inside of surface (W)

These are used for output variables "Surface Inside Face Exterior Windows Incident Beam Solar Radiation Rate" and "Surface Inside Face Interior Windows Incident Beam Solar Radiation Rate" (and related outputs).

The amount absorbed by window layers or shades is not saved for each window. This enclosure level variable is incremented for each window:

        // Beam radiation from exterior windows absorbed in a zone or transmitted through
        Real64 BABSZone = 0.0;

So I suppose we could add yet another variable to save this for each surface, and create yet another output variable based on it.

This investigation has highlighted a lot of side calculations that aren't needed if these types of output variables (or outputs calculated from them) are not requested.

[chriswmackey]

This is awesome! I'm sorry that my response here is long overdue. I finally decided to check back after someone reminded me about this issue at the SimBuild conference.

Thank you so much for addressing this, @mjwitte . I can tell that this was not an easy fix and that you had to put some old code under a magnifying glass.

Between the reports that I got from a couple of SimBuild attendees and the responses on the PR, it seems that this problem was an issue that several others have wrestled with for a very long time. You made several people happy today when I told them this is fixed and I'm personally very grateful.

With this addressed, I'm hopeful that I can finally make some high-fidelity accounts of the E+ load balance, which is critical for certain applications of the software. Particularly for engineers wishing to use E+ for sizing who really need to see the full balance in order to trust that the calculation makes sense.

Thanks again for all of the work here and I'm really looking forward to pushing this out to our users with the 24.2 release!