-
Notifications
You must be signed in to change notification settings - Fork 392
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
Fix 8638 chiller condenser recurring warnings #9231
Conversation
@jcyuan2020 @Myoldmopar it has been 28 days since this pull request was last updated. |
…r exhaust fired absorption chillerheater.
e18d5dd
to
f320baa
Compare
…_Condenser_Recurring_Warnings
Starting review. |
// 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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."); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. 👍🏽
": Condenser flow rate = 0 sever error warning continues...", // Message automatically written to | ||
// "error file" at end of simulation |
There was a problem hiding this comment.
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));
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome 👍🏽
EXPECT_EQ(state->dataErrTracking->LastSevereError, | ||
"CalcExhaustAbsorberChillerModel: Condenser flow = 0, for Exhaust Absorber Chiller=EXH CHILLER"); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
": Condenser flow rate = 0 sever error warning continues...", // Message automatically written to | ||
// "error file" at end of simulation |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targeted, corresponding - typos.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corrected now.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targeted, corresponding - typos.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. 👍🏽
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"); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Verified building documentation. |
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…_Condenser_Recurring_Warnings
…bout the unit test.
Thank you for the corrections. I am happy with it when this |
Thanks--the
and
|
Thank you for explaining and for all the changes. This looks good from my end. |
…_Condenser_Recurring_Warnings
There was a problem hiding this 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.
…hiller_Condenser_Recurring_Warnings
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.
Reviewer
This will not be exhaustively relevant to every PR.