-
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
VariableRefrigerantFlow Terminal Unit on air loop does not test node connections #8723
Conversation
New warning for defect file.
|
@@ -422,7 +424,7 @@ class AirLoopFixture : public EnergyPlusFixture | |||
int VRFTUOutletNodeNum = 31; | |||
int VRFTUOAMixerOANodeNum = 32; | |||
int VRFTUOAMixerRelNodeNum = 33; | |||
int VRFTUOAMixerRetNodeNum = 34; | |||
int VRFTUOAMixerRetNodeNum = VRFTUInletNodeNum; |
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.
Existing unit test was not configured correctly. When testing new function the failure was due to the OA mixer return node not connected to the TU inlet node. Correcting this changed the setup needed for the unit test.
@@ -545,7 +548,7 @@ TEST_F(AirLoopFixture, VRF_SysModel_inAirloop) | |||
state->dataScheduleMgr->Schedule(state->dataHVACVarRefFlow->VRF(curSysNum).SchedPtr).CurrentValue = 1.0; // enable the VRF condenser | |||
state->dataScheduleMgr->Schedule(thisTU.SchedPtr).CurrentValue = 1.0; // enable the terminal unit | |||
state->dataScheduleMgr->Schedule(thisTU.FanAvailSchedPtr).CurrentValue = 1.0; // turn on fan | |||
state->dataScheduleMgr->Schedule(thisTU.FanOpModeSchedPtr).CurrentValue = 0.0; // set cycling fan operating mode | |||
state->dataScheduleMgr->Schedule(thisTU.FanOpModeSchedPtr).CurrentValue = 1.0; // set constant fan operating mode |
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.
Changed to constant fan for set point control.
@@ -583,7 +587,8 @@ TEST_F(AirLoopFixture, VRF_SysModel_inAirloop) | |||
state->dataLoopNodes->Node(thisTU.VRFTUOutletNodeNum).TempSetPoint = 20.0; // select 20 C as TU outlet set point temperature | |||
|
|||
InitVRF(*state, curTUNum, curZoneNum, FirstHVACIteration, OnOffAirFlowRatio, QZnReq); // Initialize all VRFTU related parameters | |||
|
|||
thisTU.NoCoolHeatOutAirMassFlow = 0.0; | |||
// the above needs correcting for air loop equipment. OA flow should be set to 0 if autosized as it is 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.
This will require a follow up issue.
thisTU.heatCoilAirInNode += 1; // revert previous change | ||
thisTU.heatCoilAirOutNode -= 1; // change index of comp node (watch for array bounds) | ||
CheckVRFTUNodeConnections(*state, curTUNum, ErrorsFound); | ||
EXPECT_TRUE(ErrorsFound); // nodes are not connected correctly |
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.
New tests to exercise node connection function. This actually found a few missed cases in function.
thisTU.heatCoilAirInNode += 1; // revert previous change | ||
thisTU.heatCoilAirOutNode -= 1; // change index of comp node (watch for array bounds) | ||
CheckVRFTUNodeConnections(*state, VRFTUNum, ErrorsFound); | ||
EXPECT_TRUE(ErrorsFound); // nodes are not connected correctly |
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.
Same functions tests for a TU as zone equipment.
…8-VRF-TU-on-AirLoopHVAC-Node-Testing
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.
@rraustad I've tested this with the defect file (and with a corrected defect file) and everything works as it should here now. Unit tests all run fine. A few comments below.
void CheckVRFTUNodeConnections(EnergyPlusData &state, int const VRFTUNum, bool &ErrorsFound) | ||
{ | ||
|
||
std::string const cTerminalUnitType("ZoneHVAC:TerminalUnit:VariableRefrigerantFlow"); |
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.
Checking with @Myoldmopar about our current best practice for declaring string constants. This is nit-picking for a one-time function, but I'd like to make sure new code doesn't perpetuate old patterns.
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.
@mjwitte I found where I had seen @lefticus document the best practice. The message is:
For any future update of const static std::string, I recommend a move to constexpr static std::string_view and updating all downstream code to avoid as many dynamic allocations as possible.
For a fuller discussion, check the main comment body of #8663. I now have a better feel for how to utilize string views; this is a really exciting change with lots of potential in our code.
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.
So constexpr static std::string_view cTerminalUnitType("string"); should be used here?
void CheckVRFTUNodeConnections(EnergyPlusData &state, int const VRFTUNum, bool &ErrorsFound) | ||
{ | ||
|
||
std::string const cTerminalUnitType("ZoneHVAC:TerminalUnit:VariableRefrigerantFlow"); |
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.
@lefticus could you document in a GitHub comment here the best practice for local variable strings? We have discussed them on calls and maybe chats, but it would be good to lock it down here. IIRC it's going to be a constexpr string_view, but I can't recall all the implications.
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.
@lefticus, use constexpr static std::string_view cTerminalUnitType("string"); 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.
@Myoldmopar @rraustad I wrote up a full explanation of what is best and what the implications may or may not be on this other PR:
…8-VRF-TU-on-AirLoopHVAC-Node-Testing
…8-VRF-TU-on-AirLoopHVAC-Node-Testing
Defect warning with revised warning format.
|
@Myoldmopar @mjwitte this should be ready 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.
@rraustad Looks good. I'll let CI make more green and the merge this.
And thanks for cleaning up the stray unit test formatting.
Pull request overview
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.
If feature, test running new feature, try creative ways to break itVerify IDF naming conventions and styles, memos and notes and defaultsIf new idf included, locally check the err file and other outputs