Revise error trap in psywfntdppb and set a reasonable W value to continue simulation

[lgu1234]

Pull request overview

When dew point reaches 100C, the calculated partial vapor pressure is greater than the barometric pressure, so that the negative W value will be calculated. In addition, the saturated vapor pressure at 100C dewpoint will approach infinity, if the vapor pressure is set to barometric pressure. In order to make simulation continue, the W value is calculated with 1 degree less (100-1 = 99). The new error message clearly show the change and why.

Work Checklist

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)
• At least one of the following appropriate labels must be added to this PR to be consumed into the changelog:
  • Defect: This pull request repairs a github defect issue. The github issue should be referenced in the PR description
  • Refactoring: This pull request includes code changes that don't change the functionality of the program, just perform refactoring
  • NewFeature: This pull request includes code to add a new feature to EnergyPlus
  • Performance: This pull request includes code changes that are directed at improving the runtime performance of EnergyPlus
  • DoNoPublish: This pull request includes changes that shouldn't be included in the changelog

Review Checklist

This will not be exhaustively relevant to every PR.

• Functional code review (it has to work!)
• If defect, results of running current develop vs this branch should exhibit the fix
• CI status: all green or justified
• Performance: CI Linux results include performance check
• Unit Test(s)
• C++ checks:
  • Argument types
  • If any virtual classes, ensure virtual destructor included, other things
• IDD changes:
  • Verify naming conventions and styles, memos and notes and defaults
  • Open windows IDF Editor with modified IDD to check for errors
  • If transition, add to input rules file for interfaces
  • If transition, add transition source
  • If transition, update idfs
• If new idf included, locally check the err file and other outputs
• Required documentation updates?
• ExpandObjects changes?
• If output changes, including tabular output structure, add to output rules file for interfaces

[lgu1234]

The dew point input of 100C as input is used to calculate W in psywfntdppb. The calculated vapor pressure is greater than the barometric pressure. In order to get reasonable humidity ratio, the previous commit provided a possible humidity ratio using 99C TDP (instead of 100C TDP as input) to calculate vapor pressure, so that the vapor pressure is less than the barometric pressure. Results are good in two test files. However, the CI results from the previous commit also show regression differences in an example file as ASHRAE9012016_RetailStandalone_Denver.idf. Since the barometric pressure is very low, 99C TDP ( 1 degree less than 100C TDP) is not enough to make the vapor pressure less than the barometric pressure. I used 1 degree decrement to find the possible highest vapor pressure < the barometric pressure, so that possible humidity ratio is provided. Test results are good. The differences for this example file are expected.

From this issue, I learn that it is possible for users to input physically impossible dew point. Do we allow physically impossible air properties? Shall we provide a warning to let users be aware of it, or fix it internally?

[Myoldmopar]

@lgu1234 I like these changes. I was a little concerned about your approach adding iteration and runtime but it should be a very rare case, the change is sensible, and the user is clearly informed about the issue. I'm going to test this locally briefly and then merge it in.

About your question, however:

From this issue, I learn that it is possible for users to input physically impossible dew point. Do we allow physically impossible air properties? Shall we provide a warning to let users be aware of it, or fix it internally?

Do you mean based on EPW temperature/humidity values? Or design day input values? Or other?

[lgu1234]

@Myoldmopar I talked about humidity values based on given dew point and local barometric pressure only. I have no intention to deal with EPW so far.

[Myoldmopar]

Pulled this branch and merged develop into it. Ran unit test. Everything looks to be in order. Merging.

@lgu1234 if you would like to open up an issue for dealing with bad user input values, feel free to work up a defect example of it and we can address it there.