Fix Unitary System Multispeed Heat Pump Not Propagating Error Flag

[mitchute]

Pull request overview

The unitary system getDesignSpecMSHPdata function has an errorsFound flag that was getting passed by value. However, right above it it's clear it should be passing by ref so errorsFound can be bubbled up to the where it should fatal out when errors are raised.

Description of the purpose of this PR

Pull Request Author

• 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
• If adding/removing any output files (e.g., eplustbl.*)
  • Update ..\scripts\Epl-run.bat
  • Update ..\scripts\RunEPlus.bat
  • Update ..\src\EPLaunch\ MainModule.bas, epl-ui.frm, and epl.vbp (VersionComments)
  • Update ...github\workflows\energyplus.py

Reviewer

• 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

[mitchute]

This doesn't match the name of the test ("ZeroCoolingSpeedTest"). @rraustad thoughts on whether this or the test name needs to change?

[rraustad]

Well first off, the name of this new object, MultiSpeed Performance doesn't match what is used in the UnitarySystem object as Sys 1 Furnace DX Cool Unitary System MultiSpeed Performance at line 26819. So I would guess this new object isn't even used and the rest of the unit test (e.g., EXPECT_EQ) wasn't affected. I'm not exactly sure what this "ZeroCoolingSpeedTest" is testing for but I suspect if the name of the UnitarySystemPerformance:Multispeed is corrected it will quickly become apparent.

[mitchute]

Good catch, I thought I corrected that. Just checked locally, and either way, it doesn't appear to matter what the name is. Fun.

[rraustad]

It may not matter in this unit test, but I hope it matters in a simulation. I do see that the EXPECT_EQ's are looking for the cooling coil to be off. Whether that's a result of the multispeed performance object (obviously not) or something else is the question. I think the unit test is testing this line so adding a multispeed performance object will likely not change the result.

thisSys->m_CoolingSpeedNum = 0;

[mitchute]

It looks like getDesignSpecMSHPIndex raises a severe error message and returns a -1 when a matching object isn't found. However, errorsFound never gets raised. There also are a handful of places where we are doing something if the index is >-1 (i.e. we have a valid, named performance object), but then don't catch the other side of it.

Are there any legitimate cases where we don't find the object, and then just continue on? It seems to me we should either find a valid object, or fatal out. Thoughts?

[rraustad]

I think it would be fair to say that if the inputs are blank then -1 is valid, otherwise a valid object should be found.

[rraustad]

Agreed!

    DesignSpecMSHP::getDesignSpecMSHPdata(state, errorsFound);

    if (errorsFound) {
        ShowFatalError(state, "Design Specification MultiSpeed Heat Pump: Previous errors cause termination.");
    }

[rraustad]

So with this fix how could the original unit test have completed without fatal'ing out?

[mitchute]

See this comment