Fix 11373 - Desuperheater doesn't work with air-cooled refrigeration condenser

[kevin-moos]

Pull request overview

• Fixes Desuperheater doesn't work with air-cooled refrigeration condenser #11373

Description of the purpose of this PR

The control zone loop in GetZoneEquipmentData calls into GetRefrigeratedRackIndex which calls into CheckRefrigerationInput to load refrigeration components. This works when GetZoneEquipmentData only has one control zone to process, but when there are multiple control zones, the refrigeration components fail to load correctly and severe errors occur. I tried to refactor this loop into two loops, but unit test and regression test failures ensued. Then I noticed that there is already redundant logic in InitHeatingCoil to handle situations like this, so I simply removed the logic around GetRefrigeratedRackIndex and the problem was solved. GetRefrigeratedRackIndex wasn't referenced anywhere else, so I removed that as well.

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

[rraustad]

Why move this? This loop is only for ZoneHVAC:EquipmentConnections objects so setting this once, before the loop, seems reasonable. It's not a big deal but why set a string multiple times inside the loop?

[kevin-moos]

This was originally inside the loop. I moved it as part of a different commit which I later rolled back. I'll get this cleaned up.

[rraustad]

I agree with this comment. However, all the coils will be gotten in getInput, but for this coil InitHeatingCoil will also be called. So if Refrigeration equipment hasn't been loaded yet then it also won't be loaded yet when InitHeatingCoil is called for this coil. If, say, coil 5 is the desuperheating coil, then by the time coil 5 is called then refrigeration equipment will likely be set up. But what if coil 1 is the desuperheating coil? Not sure how to delay this setup in InitHeatingCoils, or even if that section of code executes each iteration (I hope not) but these code execution timing issues pop up now and then and we need to be sure it works regardless of which coil (index) is called first (i.e., refrigeration equipment must be gotten before this setup in InitHeatingCoils can execute correctly). The code I am referencing is new line 1386 in this branch (old line 1482 in develop).

[kevin-moos]

The timing issue I ran into wasn't with the coils, but the ZoneHVAC:EquipmentConnections objects. As long as those were all loaded before refrigeration (and coils) the order of the coils didn't seem to matter.

[rraustad]

OK, as long as this was thought about again so this doesn't pop up in the future.

[amirroth]

This is a larger, longer-term "fix" but you can use init_state to control the order in which objects get read from the IDF file and initialized. A few object types (mostly ones that don't reference other objects like Schedule, FluidProperties, Material, etc.) are already done this way.

[mitchute]

I don't see any problems here. Nice to have a PR that enhances functionality with a net-reduction in code (excepting the unit tests) :)

[mitchute]

I suspect something is going on with when I have multiple CI machines running, but when I only have one running, it seems to be working. Bumping CI again here to test my theory.

[mitchute]

One more test with a different CI machine running.

[mitchute]

Alright, I hate it, but we're doing one more test here. This CI machine passed on another branch, but not here, so... still working to figure out what is going on.

[mitchute]

All good here. Merging.