Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix 8638 chiller condenser recurring warnings #9231

Merged

Conversation

jcyuan2020
Copy link
Contributor

@jcyuan2020 jcyuan2020 commented Jan 10, 2022

Pull request overview

NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE

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

@jcyuan2020 jcyuan2020 added Defect Includes code to repair a defect in EnergyPlus Documentation Related primarily on the LaTeX-based EnergyPlus documentation labels Jan 10, 2022
@nrel-bot-2
Copy link

@jcyuan2020 @Myoldmopar it has been 28 days since this pull request was last updated.

@mjwitte mjwitte added this to the EnergyPlus 22.1 milestone Feb 8, 2022
@jcyuan2020 jcyuan2020 force-pushed the fix-8638_Chiller_Condenser_Recurring_Warnings branch from e18d5dd to f320baa Compare March 2, 2022 18:18
@jcyuan2020 jcyuan2020 marked this pull request as ready for review March 2, 2022 18:29
@jmythms
Copy link
Contributor

jmythms commented Mar 15, 2022

Starting review.

Comment on lines 1804 to 1809
// Optional<Real64 const> ReportMaxOf, // Track and report the max of the values passed to this argument
// Optional<Real64 const> ReportMinOf, // Track and report the min of the values passed to this argument
// Optional<Real64 const> ReportSumOf, // Track and report the sum of the values passed to this argument
// std::string const &ReportMaxUnits, // optional char string (<=15 length) of units for max value
// std::string const &ReportMinUnits, // optional char string (<=15 length) of units for min value
// std::string const &ReportSumUnits // optional char string (<=15 length) of units for sum value
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this code for debugging?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lines were used in the initial experiment; they are now removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏽

if (this->lCondWaterMassFlowRate_Index == 0) {
ShowSevereError(state, "CalcGasAbsorberChillerModel: Condenser flow = 0, for Gas Absorber Chiller=" + this->Name);
ShowContinueErrorTimeStamp(state, "");
// ShowFatalError(state, "Program Terminates due to previous error condition.");
Copy link
Contributor

@jmythms jmythms Mar 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this ShowFatalError(state, "Program Terminates... line can be deleted safely now, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. I think it was left as a comment from previous change somehow deliberately, considering that there are a few places in the code (also spotted in a couple places in the older code) that the developers massaged a little bit on whether to call the fatal error. So I would probably leave it as is, or a "special" note here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. 👍🏽

Comment on lines 1801 to 1802
": Condenser flow rate = 0 sever error warning continues...", // Message automatically written to
// "error file" at end of simulation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sever - typo. Also consider using format():

ShowRecurringSevereErrorAtEnd(state,
                                              format("CalcExhaustAbsorberChillerModel: Condenser flow = 0, for Exhaust Absorber Chiller={}: "
                                                     "Condenser flow rate = 0 severe error warning continues... {}",
                                                     this->Name,
                                                     this->lCondWaterMassFlowRate_Index));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This has now been corrected and the "format" style is used.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome 👍🏽

Comment on lines +1428 to +1429
EXPECT_EQ(state->dataErrTracking->LastSevereError,
"CalcExhaustAbsorberChillerModel: Condenser flow = 0, for Exhaust Absorber Chiller=EXH CHILLER");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line passes with the current develop branch code, was that the expected behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is part of the expected behavior (and also required) for testing these error messages. I am also considering adding one check for "at end" part that you suggested.

Comment on lines 1732 to 1733
": Condenser flow rate = 0 sever error warning continues...", // Message automatically written to
// "error file" at end of simulation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"sever" typo here as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks--this has now been corrected as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏽

The delta temperature difference {[}$\Delta{^\circ}C${]} between the setpoint and the ``cut-in'' temperature at which the heater will turn on. In other words, the ``cut-in'' temperature is Setpoint -- Deadband.

One note here is that if a source side connection exists, how this \emph{Deadband Temperature Difference} is used is dependent on the ``\emph{Source Side Flow Control Mode}''{[}\ref{field-source-side-flow-control-mode}{]} choice. If \emph{Source Side Flow Control Mode} is \emph{IndirectHeatPrimarySetpoint} or
\emph{IndirectHeatAlternateSetpoint}, the targedted ``cut-in'' temperature is the related Setpoint -- Deadband as described above. However, when the \emph{Source Side Flow Control Mode} setting is \emph{StorageTank}, the deadband is not used in getting the ``cut-in'' temperature---so in this case it is just directly using the correponding Setpoint temperature without subtracting off the Deadband Temperature Difference.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

targeted, corresponding - typos.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Corrected now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏽

The delta temperature difference {[}$\Delta{^\circ}C${]} between the set point and the ``cut-in'' temperature at which Heater 2 will turn on. In other words, the ``cut-in'' temperature is Set Point -- Deadband.

One note here is that if a source side connection exists, how this \emph{Deadband Temperature Difference} is used is dependent on the ``\emph{Source Side Flow Control Mode}''{[}\ref{field-source-side-flow-control-mode}{]} choice. If \emph{Source Side Flow Control Mode} is \emph{IndirectHeatPrimarySetpoint} or
\emph{IndirectHeatAlternateSetpoint}, the targedted ``cut-in'' temperature is the related Setpoint -- Deadband as described above. However, when the \emph{Source Side Flow Control Mode} setting is \emph{StorageTank}, the deadband is not used in getting the ``cut-in'' temperature---so in this case it is just directly using the correponding Setpoint temperature without subtracting off the Deadband Temperature Difference.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

targeted, corresponding - typos.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks--corrected now with a couple of additional minor changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've rebuilt the docs locally. Looks good! Nice catch with correcting the reference. 👍🏽

Comment on lines 1427 to 1434
EXPECT_EQ(state->dataErrTracking->TotalSevereErrors, 3);
EXPECT_EQ(state->dataErrTracking->LastSevereError,
"CalcExhaustAbsorberChillerModel: Condenser flow = 0, for Exhaust Absorber Chiller=EXH CHILLER");

thisChillerHeater.calcChiller(*state, loadinput);
EXPECT_EQ(state->dataErrTracking->TotalSevereErrors, 5);
EXPECT_EQ(state->dataErrTracking->LastSevereError,
"SetComponentFlowRate: trapped plant loop index = 0, check component with inlet node named=EXH CHILLER CONDENSER INLET NODE");
Copy link
Contributor

@jmythms jmythms Mar 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the tests pass when the ChillerGasAbsorption files are same as develop, should we add a test for ChillerGasAbsorption as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably save a repeated unit test on that if possible, considering these two types of chillerheaters follow similar (or actually the same) error reporting logic regarding the condenser flows.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it 👍🏽

auto &thisChillerHeater = state->dataChillerExhaustAbsorption->ExhaustAbsorber(1);

Real64 loadinput = -5000.0;
bool runflaginput = true;
Copy link
Contributor

@jmythms jmythms Mar 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This runflaginput variable is unused.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks--will deal with while trying adding the "at end" error message check in unit test.

@jmythms
Copy link
Contributor

jmythms commented Mar 15, 2022

Verified building documentation.

Comment on lines 1799 to 1802
ShowRecurringSevereErrorAtEnd(state,
"CalcExhaustAbsorberChillerModel: Condenser flow = 0, for Exhaust Absorber Chiller=" + this->Name +
": Condenser flow rate = 0 sever error warning continues...", // Message automatically written to
// "error file" at end of simulation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I think it would be good if the unit test could test this ShowRecurringSevereErrorAtEnd, since that was the main point mentioned in issue 8638.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree--I will try adding a check on this.

@jmythms
Copy link
Contributor

jmythms commented Mar 17, 2022

Thank you for the corrections. I am happy with it when this ShowRecurringSevereErrorAtEnd error test has been added. 👍🏽

@jcyuan2020
Copy link
Contributor Author

Thank you for the corrections. I am happy with it when this ShowRecurringSevereErrorAtEnd error test has been added. 👍🏽

Thanks--the ShowRecurringSevereErrorAtEnd() results are actually checked in the last update. This "show at end" function actually just stores the sorted error message contents and counts in an array without actually printing out for now. The storage contents for this recurring condenser flow rate one are checked via the following lines in this commit and the outcomes are expected:


    EXPECT_EQ(state->dataErrTracking->RecurringErrors(1).Count, 1);
    EXPECT_EQ(state->dataErrTracking->RecurringErrors(1).Message,
              " ** Severe  ** CalcExhaustAbsorberChillerModel: Condenser flow = 0, for Exhaust Absorber Chiller=EXH CHILLER: Condenser flow rate = 0 "
              "severe error warning continues...");

and

    EXPECT_EQ(state->dataErrTracking->RecurringErrors(1).Count, 2);
    EXPECT_EQ(state->dataErrTracking->RecurringErrors(1).Message,
              " ** Severe  ** CalcExhaustAbsorberChillerModel: Condenser flow = 0, for Exhaust Absorber Chiller=EXH CHILLER: Condenser flow rate = 0 "
              "severe error warning continues...");

@jmythms
Copy link
Contributor

jmythms commented Mar 17, 2022

Thank you for explaining and for all the changes. This looks good from my end.

Copy link
Contributor

@mjwitte mjwitte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested with some example files. The recurring errors work as advertised.

@mjwitte mjwitte merged commit bb4a584 into NREL:develop Mar 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Defect Includes code to repair a defect in EnergyPlus Documentation Related primarily on the LaTeX-based EnergyPlus documentation
Projects
None yet
8 participants