Fix issue where simple glazing system had negative absorptance at some incident angles

[nealkruis]

Pull request overview

Fixes #8000

The formulation of the reflectance curves for the simple glazing method are independent of the transmittance curves and, as a result, the combined transmittance + reflectance can be greater than 1.0 (making absorptance less than zero). Negative absorptance generally only happens at high angles of incidence. Under these conditions, heat will be emitted from the glazing, reducing the cooling load in the respective zones.

The solution implemented reformulates the reflectance curve data into the same formulation that is used for the coated glass angular properties. This can be done algebraically using the original reflectance coefficients for curves A-J. I will also add a final energy balance check to enforce a lower limit on absorptance.

The reformulation of curve values is illustrated in this spreadsheet. This illustrates the conversion from the original reflectance curves to the reformulated curves through two steps: 1) Normalization (to make "New" curves), and 2) accounting for transmittance (to make "New Coefficients" curves). This does not impact the transmittance curves (though, the transmittance curve coefficients have been rounded with negligible impact on results).

Here is an example of glazing optical properties before and after the fix (see details in this comment):

These modifications are described in the engineering documentation.

Diffs are expected in all test files using WindowMaterial:SimpleGlazingSystem (currently 52 files).

Reference Building Diffs

Most of the files that are showing diffs are the reference buildings (and files based on them). Some key diffs from annual simulations of the base RefBldg* files are shown below.

• The 10% change in gas use for RefBldgMediumOfficeNew2004_Chicago is concerning.
• And there are some large sizing differences for certain zones in various buildings that is worth investigating more closely.

File	Delta Electricity	Delta Gas	Max Zone Flow Rate Diff	Zone
RefBldgFullServiceRestaurantNew2004_Chicago	0.4%	0.3%	5.5%	DINING
RefBldgHospitalNew2004_Chicago	0.2%	0.1%	19.4%	OFFICE2_MULT5_FLR_5
RefBldgLargeHotelNew2004_Chicago	0.5%	0.1%	17.6%	RETAIL_1_FLR_1
RefBldgLargeOfficeNew2004_Chicago	0.8%	0.6%	26.1%	PERIMETER_BOT_ZN_1
RefBldgMediumOfficeNew2004_Chicago	1.1%	10.0%	29.7%	PERIMETER_BOT_ZN_1
RefBldgMidriseApartmentNew2004_Chicago	0.7%	1.2%	4.8%	M NW APARTMENT
RefBldgOutPatientNew2004_Chicago	0.9%	2.0%	17.4%	FLOOR 2 EXAM 4
RefBldgPrimarySchoolNew2004_Chicago	0.8%	2.3%	20.0%	LOBBY_ZN_1_FLR_1
RefBldgQuickServiceRestaurantNew2004_Chicago	0.3%	0.2%	2.4%	DINING
RefBldgSecondarySchoolNew2004_Chicago	1.0%	0.9%	25.4%	LOBBY_ZN_1_FLR_1
RefBldgSmallHotelNew2004_Chicago	0.5%	0.4%	6.6%	FRONTLOUNGEFLR1
RefBldgSmallOfficeNew2004_Chicago	0.6%	2.4%	3.8%	PERIMETER_ZN_3
RefBldgStand-aloneRetailNew2004_Chicago	0.6%	0.6%	11.2%	FRONT_RETAIL
RefBldgStripMallNew2004_Chicago	0.9%	1.0%	6.7%	SMSTORE1
RefBldgSuperMarketNew2004_Chicago	0.02%	0.4%	0.0%
RefBldgWarehouseNew2004_Chicago	Small	Small	0.0%

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 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
• Review doc changes (content, spelling, formatting) in pdfs

[nrel-bot-2b]

@nealkruis @lgentile it has been 29 days since this pull request was last updated.

[nrel-bot-3]

@nealkruis @lgentile it has been 28 days since this pull request was last updated.

[nealkruis]

@EnergyArchmage I updated the documentation to clarify the change in the form of the reflectance curve and its coefficients. Please let me know if you have any questions. Otherwise, we're just waiting on results back from the CI...

[EnergyArchmage]

why is this line repeated? copy paste error?

[nealkruis]

You know...just in case the first attempt is a false positive! 😄

...good catch.

[nealkruis]

Actually, no...it's not the same. The first is the front reflectance rfp, the second is the back reflectance rbp. Transmittance is the same in both directions tfp.

[EnergyArchmage]

I have reviewed the code and approve this PR. Unfortunately I don't have enough data capacity to download the entire forked repo and so couldn't pull down the branch and do all the usual review things.

[mjwitte]

@nealkruis Some initial comments. Comparing annual energy use. The difference in site energy for the defect files is roughly 2.5%, for RefBldgFullServiceRestaurantNew2004_Chicago, it's roughly 0.035%. Did you review annual energy results for any other testfiles that use simpleglazing? Just want to be sure this isn't introducing major differences in energy use for more "normal" glazing inputs.

[nealkruis]

@mjwitte I made sure that the only files impacted were those with WindowMaterial:SimpleGlazingSystem. It wouldn't hurt to have an external review to confirm.

[mjwitte]

@nealkruis I'll review some annual diffs. There are a couple of unit test failures. Also, I'd like to see for a "typical" window from one of the test files (probably one of the Ref* buildings, how the internal window properties change before and after this change. And show some plots of the angular window transmission on a winter day and summer day to see how similar or not the performance is. And how does the plot shown in the original issue look now with this fix?

[nealkruis]

Sorry, @mjwitte, I thought I posted these earlier. These are all figures comparing window outputs between the simple and detailed (layer-by-layer) model for the ASHRAE 140 L130AC glazing definition. Each point is one hour from the annual simulation.

The x-axis here is angle of incidence (anything less than zero is purely diffuse radiation).

One important thing to recognize here is how the frame is characterized in each model. The spectral results in the detailed model do not include the frame (this is why transmittance looks so much higher in this model). The best (and only real apples-to-apples comparison) here is the "Net Window Heat Transfer", which is one of the only outputs that includes the frame effects.

Here are the figures before the fix:

Here are the figures after the fix:

[mjwitte]

@nealkruis See summary of Reference Building Diffs above. RefBldgMediumOfficeNew2004_Chicago has a 10% increase in gas use. Please look at that and provide some justification. Also, there are some major sizing changes (up to 30%) for particular zones in the other reference buildings. We need to understand what's driving that. Otherwise, the annual energy diffs for the other reference buildings are on the order of 1-2%, so that's reasonable.

[nealkruis]

@mjwitte I think the gas use variance in the medium office is related to the fact that it uses electric reheat to meet most of the heating demand in the building, and only uses gas for heating in the central VAV system. It could be a small denominator that's inflating the % difference? Other buildings use all gas, or hot water reheat from a gas boiler. The differences on a time step basis are definitely happening when solar gains are offsetting the heating load (as is expected). I'd have to think more about how the heating system works with this building to understand why/how the central heating coils are picking up more of the load during hours with solar gains. Any ideas?

Looking at the sizing flow rates, it's clear that the difference is also related to solar gains. Below is the plot for the cooling design air flow rate from the zone sizing run for medium office, bottom perimeter zone 1. It's clear that solar is a large component of the load, and the fix shows a smoother peak that you'd expect from the sun's path relative to the windows in the zone. We know that absorptance in "develop" is less than in "fix" and negative at some incident angles, which will decrease loads somewhat (depending on the relative magnitude of solar transmission).

This plot is consistent with what I showed with the net window heat transfer rate in the L130AC building where, depending on the incidence angle, the net window load could be 50% lower in the simple glazing model without the fix.

I don't know if that satisfies your concerns or not. I'll keep thinking about the medium office gas use, but I thought I'd share my ideas in the meantime.

[nealkruis]

Another strange thing about the medium office results is that the gas central heating is 24 GJ lower and electric reheat heating is 11 GJ higher after the fix. The overall heating loads are not actually changing that much (~1-2%).

The total heating energy in this model before this fix was 70% electric and 30% gas. After the fix it is closer to 75%/25%. I still don't have an explanation for why the load is shifting from electric reheat to central gas, but I do think that the shift combined with the small fraction of heating that is met with gas explains why the medium office appears to be an outlier.

[mjwitte]

@nealkruis For the zone shown above (bottom perimeter zone 1) that is a huge change in cooling airflow rate. What direction(s) does the glazing face for that zone? I would expect this to cause an increase in reheat energy use due to the higher minimum airflow rate into that zone. There won't be any change to heating sizing, because the winter design days all assume no solar. But what's the change in annual heating load for that zone? The AHUs have a fixed (scheduled) supply air setpoint of 12.8C (55F), so the central gas heating coils are only treating OA load in cold weather. These systems have draw-through fans, so my guess is that the higher fan heat (due to the higher cooling airflow sizing and fixed min VAV flow fractions) is offsetting the heating gas.

[nealkruis]

@mjwitte bottom perimeter zone 1 is south facing. It's the summer design day, so I expect the incident angle is pretty low during the peak (maybe its worth plotting incident angle for the design day run?). I think I would expect this fix to have a similar effect on any equator-facing perimeter zone.

I think you're right about the fan heat changing the gas load. The difference is pretty constant through out the day, whereas the reheat definitely shows more of the variation we expect from this fix with greater differences in the morning and late afternoon when the sun is at lower angles.

[nealkruis]

@mjwitte I added the a sheet ("Comparisons") to google workbook to visualize the impact of the fix on Transmittance, Reflectance, and Aborptance as a function of incident angle for any curve. The inputs are normal transmittance/reflectance and curve letter.

For the medium office (and I think most of the reference models), the U-factor is 3.24 and the SHGC is 0.39. This combination results in normal transmittance of 0.304, normal reflectance of 0.4662, and puts us squarely in the average of curves FGHI. Here are plots for each of absolute transmittance/reflectance/absorptance for each of these curves (notice the y-axis scale is changing):

F:

G:

H:

I:

I can also add the FGHI average if you want to look at it, but it will be somewhere between F and G (F and H are nearly identical).

[mjwitte]

@nealkruis EnergyPlusFixture.HeatBalanceManager_EMSConstructionTest is failing on my local Windows build on the new assert(1 - rfp - tfp >= 0.0);
rfp = 0.10000000000000010 and tfp = 0.90000000000000024.

[mjwitte]

Since the unit test needs a fix, there's some minor doc changes as well.

[mjwitte]

Typo (that was there before) "mapped to set of 28 bins ..."

[mjwitte]

"The correlations for transmittance has the form:" Correlations or hashave ?

[mjwitte]

In the code -2.53 is -2.52.

[mjwitte]

In the code -3.14 is -3.15. Similar differences on the same coefficient for G and I. Also some minor differences in coefficients c, d, and e for several rows.

[mjwitte]

FYI, CI did report the unit test failures above on Linux UnitTestsCoverage-Debug.

[mitchute]

@nealkruis It looks like there are still a few issues here. Are you planning on getting this in before release?

[mitchute]

Also, I've confirmed the unit test failure on a local Linux machine.

[EnergyArchmage]

I believe this is an important fix and should be a priority.

…

On September 18, 2020 12:03:55 PM EDT, Matt Mitchell ***@***.***> wrote: @nealkruis It looks like there are still a few issues here. Are you planning on getting this in before release? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #8001 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[nealkruis]

@mitchute @mjwitte I plan to resolve this today (sorry for the delay). It may be specific to the unit test where normal trans + refl = 1.0 + floating point inexactness. I will add an epsilon to the floating point comparison. I might also check to make sure users can't input trans + refl > 1.0 + epsilon. I'm hoping there's some code to catch that somewhere.

[nealkruis]

Interesting:

  double T = 0.9;
  double R = 0.1;
  1.0 - T - R >= 0;  // This is false (and why my assertion breaks)
  T + R <= 1.0;  // This is true (and why the get input routine doesn't have a problem with these values)

I fixed the assertion in to allow for minor floating point precision issues, but this makes me feel a little uneasy about not adding an epsilon to the get input routine as well.

[mjwitte]

Interesting:

 double T = 0.9;
 double R = 0.1;
 1.0 - T - R >= 0;  // This is false (and why my assertion breaks)
 T + R <= 1.0;  // This is true (and why the get input routine doesn't have a problem with these values)

I fixed the assertion in to allow for minor floating point precision issues, but this makes me feel a little uneasy about not adding an epsilon to the get input routine as well.

@nealkruis There are many different checks for various input combinations >1.0 for WindowMaterial:Glazing here and following. If I'm understanding your concern, all of these would need to be modified to allow for an epsilon. I wouldn't touch any of that now, and I don't think it's a problem. If you want to post a new issue to explore this further (post v9.4 release) that's fine, but I wouldn't change anything here.

@Myoldmopar Any further thoughts? I'm ready to merge this.

[Myoldmopar]

No, nothing further from me. I'm glad things are working well, and support pushing further changes off until later.