Pull request overview

Description of the purpose of this PR

Currently, EnergyPlus does not have a direct or explicit way to model passive hot water tanks , which stores hot water in a way that naturally maintains temperature stratification without the use of active mixing or heating elements. Users have used the heat pump water heater, WaterHeater:Mixed and WaterHeater:Stratified with tricks and limitations. This hinders the ability of users to model complex thermal energy storage systems.

Key drawbacks of the existing tank object include,

• Ambiguity in Control: Due to the dual purpose of the water heater and water
  storage tank, it is sometimes unclear whether the setpoint temperature
  controls the source side flow request or the internal heater operation.
• Fixed Flow Direction: In complex HVAC systems, such as the Time Independent
  Energy Recovery (TIER) system defined in [1] defined in , the water flow
  direction may change. For example, in the heating mode, water flows in at the
  bottom and exits at the top of the tank, whereas in the cooling mode, water
  flows in at the top and exits at the bottom. The current object has fixed
  inlet and outlet water heights, thereby only allowing a fixed flow direction.
  In contrast, the water storage tank implemented in Modelica is more flexible
  [2], with the flow direction indicated by the sign of the flow. Additionally,
  temperature sensors can be placed in all layers (at different heights) of the
  stratified tank, providing information for more complex control logic.
• Simplified Charging Logic: The current object determines tank charges (source
  side requesting water flow) based on a temperature setpoint (default) or a
  temperature upper limit (storage tank mode). However, more complex charging
  control is sometimes needed. For example, in some applications, the charging
  percentage needs to be a function of the tank temperature, which could involve
  temperature of all stratified layers. The current object does not allow for
  such complex charging percentage calculations nor does it permit control of
  this parameter via EMS or Python plug-ins.
• Issue with autosizing: Tank autosizing capability is present but with
  multiple issues (issue 8412, 8451, 9956). Actuators might need to be added to
  enable auto-sizing with external code (EMS or python API), especially for
  complex systems with heat pumps, heat recovery chillers, and thermal storage
  tanks.

The proposed new feature will introduce a passive hot water tank, similar to the
chilled water tank, but designed to hold hot water. It will also include various
actuators to control flow direction and tank charging. The autosizing
functionality will be thoroughly tested to ensure it functions properly. This
new tank can be incorporated into complex energy recovery systems like the TIER
system.

Regression diffs

• 6 files with rdd diffs: this is caused by the change of output names for chilled water tank, where previously some fields are called "Thermal Storage ...", some are called "Thermal Storage Tank ...". This PR unified the names all to "Thermal Storage Tank..."
• 2 files with audit diff: the feature branch NumOfRVariable is 2 greater than the develop branch. This is because 2 reporting variables are added:

Output:Variable,*,Chilled Water Thermal Storage Tank Temperature Setpoint,hourly; !- HVAC Average [C]
Output:Variable,*,Chilled Water Thermal Storage Tank Temperature Sensor Value,hourly; !- HVAC Average [C]

Function illustration

The following illustrations uses the PlantLoopHeatPump_EIR_AirSource_BufferTank.idf file.

two setpoints controlling charging
The hot water tank in this PR can control its charging with two setpoints: when the top temperature < setpoint - deadband or the bottom temperature < setpoint - deadband, the tank will charge. Otherwise it will not charge. In the following example, the setpoint at the top of the tank is 21C, the setpoint at the bottom of the tank is 15C. For simplicity, the dead band temperature is set to be very small.

flow direction switch
The new hot water tank object can switch the flow direction on the source side or the use side. The flow direction is controlled with a schedule. When the value is 1, it keeps the original direction, when it's -1, it reverses the direction. In the following example, the use side orginal flow direction draws water from the top, while the reverse direction will swap the use inlet and outlet node and draws hot water from the bottom. The tank temperature is higher when the use side flow direction is reversed, as cold water are removed on the tank use side.

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

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