chris
May 24, 2024, 12:51am
21
@charlie.brooker and everyone else on this thread,
I have some very delayed but nevertheless good news. It turns out that what we were looking at here with an overestimation of glazing loads (and corresponding nonsensical storage term) was, in fact, a bug in EnergyPlus . The bug did NOT affect the accuracy of the EnergyPlus load balance and you can rest assured that the first law of thermodynamics is being upheld in your simulations. However, EnergyPlus’s reporting of total energy transfer across the windows was not correct. From what I could tell, the beam solar energy that is back-reflected out of the window to the outdoors was not being included as it should be.
Michael Witte and a couple of other EnergyPlus developers dug through some ancient EnergyPlus code to identify the issue and they have pushed a fix to EnergyPlus here:
NREL:develop
← NREL:WindowAndSolarOutputs
opened 09:04PM - 20 Mar 24 UTC
Pull request overview
---------------------
- Fixes #10333
- Correct "Surf… ace Inside Face Initial Transmitted Diffuse Transmitted Out Window Solar Radiation Rate" (`state.dataHeatBal->SurfWinInitialDifSolInTransReport, SurfWinInitialDifSolInTrans`) and "Surface Window Shortwave from Zone Back Out Window Heat Transfer Rate" (`state.dataSurface->SurfWinLossSWZoneToOutWinRep`) to be (1-Reflected) solar. Previously, these were calculated using the diffuse transmittance which omits the solar absorbed in the glass on the way out.
- When using full interior solar distribution, some direct beam solar can leave the zone when it is incident on the inside face of a window (interior or exterior). This component is now added to "Surface Window Shortwave from Zone Back Out Window Heat Transfer Rate".
- Correct "Surface Window Net Heat Transfer Rate" and related outputs to subtract "Surface Inside Face Initial Transmitted Diffuse Transmitted Out Window Solar Radiation Rate". Previously, this term was omitted, so the window heat gain was overstated. Related outputs include "Surface Window Heat Gain Rate/Energy" and "Surface Window Heat Loss Rate/Energy". *Note that there may be significant changes in these outputs for highly glazed enclosures.*
- Fixes eio output for WindowConstruction to write the values for Solar Transmittance at Normal Incidence and Visible Transmittance at Normal Incidence. Previously, the format did not have enough terms, so the last two values were not written.
### Expected Diffs
- **NO mtr diffs** because none of the impacted calculations are actually used in the heat balance, they are all side calcs used to generate various output variables.
- **eio diffs** due to missing terms in the WindowConstruction report. And equivalent table diffs in the Initialization Summary report, e.g. PurchAirWindowBlind:
```
- WindowConstruction,WIN-CON-SINGLEPANE,5,1,VerySmooth,5.894,5.894,1.000,0.919
+ WindowConstruction,WIN-CON-SINGLEPANE,5,1,VerySmooth,5.894,5.894,1.000,0.919,0.900,0.900
```

- **eso diffs** for any of the affected output variables
- **Table diffs** for the Sensible Heat Gain Summary, because Surface Window Heat Gain Energy (and Loss) are used for the "Window Heat Addition/Loss" columns in this report, e.g. percent diff output for _5ZoneAirCooled_annual:

### ToDo List
- [ ] Unit test
- [ ] I/O Ref updates, maybe Engineering Ref?
- [ ] Confirm that the correct reflectance values have been used for the various window types (normal, complex, and equivalent layer).
- [ ] Demonstrate solar and energy balances with defect file.
- [ ] Check results for all variations of solar distribution (so far FullExterior looks good).
- [ ] Demonstrate solar and energy balances with defect file.
- [ ] Some minor refactoring to avoid extra multiplications.
- [ ] A separate no-diff PR with some additional code cleanup (e.g. reduced variable scope, reference assignments, avoid duplicate code where possible, etc.).
### Pull Request Author
Add to this list or remove from it as applicable. This is a simple templated set of guidelines.
- [ ] Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
- [ ] Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
- [ ] Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
- [ ] Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
- [ ] If any diffs are expected, author must demonstrate they are justified using plots and descriptions
- [ ] If changes fix a defect, the fix should be demonstrated in plots and descriptions
- [ ] If any defect files are updated to a more recent version, upload new versions here or on DevSupport
- [ ] If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
- [ ] If structural output changes, add to output rules file and add OutputChange label
- [ ] If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies
### Reviewer
This will not be exhaustively relevant to every PR.
- [ ] Perform a Code Review on GitHub
- [ ] If branch is behind develop, merge develop and build locally to check for side effects of the merge
- [ ] If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
- [ ] If feature, test running new feature, try creative ways to break it
- [ ] CI status: all green or justified
- [ ] Check that performance is not impacted (CI Linux results include performance check)
- [ ] Run Unit Test(s) locally
- [ ] Check any new function arguments for performance impacts
- [ ] Verify IDF naming conventions and styles, memos and notes and defaults
- [ ] If new idf included, locally check the err file and other outputs
And they closed out the issue that I opened on the EnergyPlus GitHub:
opened 10:09PM - 15 Dec 23 UTC
closed 01:51PM - 03 May 24 UTC
Issue overview
--------------
After [not finding an explanation on Unmethours]… (https://unmethours.com/question/97631/help-with-constructing-the-simplest-load-balance-with-energyplus/), 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`](https://bigladdersoftware.com/epx/docs/23-2/input-output-reference/group-thermal-zone-description-geometry.html#surface-window-net-heat-transfer-rate-j)
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.
- [x] 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)
The fix is not yet in a stable release of EnergyPlus but it has been merged into their code base and we will have it available when we eventually upgrade to EnergyPlus 24.2 at the end of this year.
Until we make the switch, I am going to leave the 6% fudge factor in the Ladybug Tools source code of our load balance because it is still more accurate than using the existing E+ output with the bug in it.
But thanks again to everyone who helped us find this issue. Judging from the explanation on the E+ GitHub, it sounds like this bug might have existed in E+ for over a decade and arose when they first introduced more advanced solar distribution methods. I also just came back from the IBPSA USA conference and there were two other people there who had encountered this situation before but were unsuccessful in getting it fixed.
So, once again, a huge thanks is due to Michael Witte. I have not had the pleasure of meeting him in person but, if any of you get to him before me, please thank him for me.
8 Likes
Thank you so much for investigating, raising the issue with E+, and reporting back @chris , @Michael and I had no idea this post would turn into such a big investigation!
Thanks also have to go to Michael Witte!
Looking forward to the new version of E+ at the end of the year
1 Like
Hey @chris , hope you’re doing well!
Is there any update on when LBT will be upgrading to E+ 24.2?
We’re back on some solar gain comparisons between IES and E+ and although we’ll continue regardless it would be great to know that this bug has been squashed out of the LBT suite.
Cheers,
Charlie
1 Like