UnitarySystem heating coil control problem with multi-speed fan - possible sizing issue

rraustad commented 6 years ago

Issue overview

Summary by @mjwitte based on testing with v9.0.1, Oct 2018

Issues

Unitary system with Coil:Gas:Heating and multispeed fan, control works well for larger autosized coil, but smaller coil results in max iterations and bogus results.
With Coil:Heating:Gas:MultiStage control is good, but airflow is wrong, either sits at high or low, but does not split the timestep between two speeds as it should.
Autosizing may be oversizing the heating coil, have not confirmed that.

3 v9.0 defect files in EnergyPlusDevSupport, run them with Chicago weather.

Details

Defect file has three AirloopHVAC:UnitarySystem with load control, each serving a single zone (focus on CoreZone here) with multi-speed fan operation. For heating, the fan flow is 1.0. For no-load the fan flow is 0.25. Fan operation is continuous during occupied hours.

With autosized Coil:Heating:Fuel (83.7kW), the system runs fine and controls well, even for an annual simulation. There are some DX cooling coil flow/capacity warnings, but no max iterations problems. During heating, the thermostat setpoint is met (within 0.01C) and there is no overheating. The fan speed outputs show for each timestep that the system is splitting the timestep between coil-on 100% flow and coil-off 25% flow to meet the current zone load.

But with fixed size Coil:Heating:Fuel (33.2kW), it struggles to control during heating. There are max iteration warnings, the zone temperature is often below setpoint, and there are times when the system is oscillating between 25% flow and 100% flow. It's interesting to note that some parts of the day, it controls well, but not in others.

Results comparison below has the smaller heating coil on the left, the larger autosized heating coil on the right. The highlighted cells tell the story. The reported mixed air temp is not consistent with the flow rate, the fan speed is all high or all low, the zone setpoint is not met, and the heating coil is unnecessarily maxed out.

Background (from April 2018)

User noticed odd results when testing Coil:Heating:Fuel and Coil:Heating:Gas:MultiStage as described in HelpDesk Ticket 12594. Defect files are attached to that ticket.

Original post from HelpDesk ticket 12594:

Tiejun Wu (Staff Engineer)USER Posted on: 23 March 2018 12:22 PM I met some issues when trying to model a roof top unit with staged air flow using the AirLoopHVAC:UnitarySystem object.

The unit I model is a 4 stage DX cooling, single stage gas heating unit. In which each cooling stage corresponds to an air flow ratio (0.25, 0.5, 0.75, 1.0). When operating in heating mode, the air flow ratio is 1.0. When operating in no cooling/heating mode, the air flow ratio is 0.25. I used the “UnitarySystemPerformance:MultiSpeed” object to specify the air flow ratio.

I tried to model the gas heating coil with two different objects “Coil:Heating:Fuel” and “Coil:Heating:Gas:MultiStage”. For each approach, I see some issues.

In the first model, “Office_Chicago_CoilHeatingFuel.idf”. The gas heating coils are modeled with “Coil:Heting:Fuel” objects. The issue I see is that at some time steps when the zone is predicted to need no cooling or heating, the RTU mixed air node temperature is not calculated correctly, which causes the heating coil to operate at maximum capacity. The following snapshot (Pic1.png) is for the Core Zone at 1/2 9:00am. For this time step, based on the return air stream and the outdoor air stream, the mixed air temperature should be around 16.90 C. But the EnergyPlus output is only 5.60 C, this causes the heating coil to run at maximum capacity and still not maintaining the zone heating setpoint. I suspect that in calculating the mixed air node temperature, the system looked at the predicted load to cooling and heating setpoint and determined that the air flow ratio should be at 0.25 which corresponds to the no cooling/heating mode. However, later the system see that heating coil should be on and changed the air flow ratio to 1.0. But the algorithm never went back to recalculate the mixed air temperature.

In the second model, “Office_Chicago_MultiStageGasHeatingCoil.idf”. The gas heating coils are modeled with “Coil:Heating:Gas:MultiStage” objects with only one stage. The issue is that during occupied hours when I have specified the fan mode to be continuous run in the unitary system object, when the zone is predicted need no cooling or heating, the supply fan shuts off rather than supplying the 0.25 air flow ratio. The following charts (Pic2.png and Pic3.png) are for NorthEast Zone and Core Zone supply fan air flow throughout 1/2. We can see that the fan was shut off for some period during the occupied hours.

Pic1:

Pic2:

Pic3:

Followup email:

I downloaded version 8.9 and ran the simulation again. Same as your plot, I see that the first issue got corrected in EnergyPlus 8.9. However, looks like in version 8.9, the autosized heating coil capacity is much bigger than those from version 8.8. See the attached screen shot of the heating coil sizing report.

I checked the heating designday simulation, and it looks like that the heating coil size from version 8.8 is sufficient to keep the zones at heating setpoint. Not sure what changes made in version 8.9 to result in the much larger sized capacity. In version 8.9, there is a "Coil Sizing Details" report that can provide some detailed data on debugging this problem.

V8.8 sizing: gasheatingcoilsizingreport_8 8

V8.9 Sizing: gasheatingcoilsizingreport_8 9

Final communication:

With Version 8.9, I fixed the size of the "Coil:Heating:Fuel" objects so that these coils won't be oversized. Then when I run the simulation again, I can see that the wrong mixed air temperature problem happens again. Looks like it works ok when the "Coil:Heating:Fuel" object is auto sized, but with fixed size coil, its not functioning properly.

Details

Some additional details for this issue (if relevant):

Platform (Operating system, version)
Version of EnergyPlus (if using an intermediate build, include SHA)
Unmethours link or helpdesk ticket number

Checklist

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

[x] Defect file added (EnergyPlusDevSupport/DefectFiles/6000s/6727)
[ ] Ticket added to Pivotal for defect (development team task)
[ ] Pull request created (the pull request will have additional tasks related to reviewing changes that fix this defect)

jasondegraw commented 5 years ago

@rraustad @mjwitte Could we get a fuller description of the issue copied over here?

mjwitte commented 5 years ago

@jasondegraw Given all the changes to UnitarySystem in v9.0, this needs to be re-run to see if the same symptoms are showing.

mjwitte commented 5 years ago

@jasondegraw @rraustad There are still issues here. Added new information at the top.

rraustad commented 5 years ago

Using 6727-Office_Chicago_MultiStageGasHeatingCoil_V901.idf defect file.

In this part of the code the Unitary System is trying to determine if the constant fan would change the load by exceeding the zone set point. There is no load at this time, ZoneLoad = 0. The first time through at 9 AM the system inlet node temp = 16.9 and mass flow = 2.6. Here when the model sets the air flow rate to the minimum, the air flow rate does change but the inlet air temp/conditions do not. At these conditions, operating the system at the No Load Supply Air Flow Rate yields an outlet air temp of 17.1 and a SensOutputOff capacity (wrt the zone) is -2632 W. This is not enough to push the zone past the heating set point and the system is off and operates at the no load air flow rate. Then the OA controller is simulated. It thinks it's return node flow = 2.6, the flow at the last time step. And sets the mixed air temp = 17.05 and back to the UnitarySystem. The same thing happens again (decides to operate at the no load flow rate with heating off). Now back to the OA controller which now sees return flow = 0.65 and sets mixed air temp = 4.9. Now the UnitarySystem sees the SensOutputOff = -10555W, which pushes zone temp beyond heating SP and the UnitarySystem sets the heating coil load = the load to heating SP of -4636W. The system goes to full flow since the outlet temp can only get to 19.3 which is lower than the zone temp (return temp = 21.09). Now back to the OA controller, return flow = 2.6 and mixed air temp is again set to 17.05 and around we go.

    // System load calculation for constant fan systems
    if (this->m_FanOpMode == DataHVACGlobals::ContFanCycCoil) {
        bool HXUnitOn = false;
        this->FanPartLoadRatio = 0.0; // sets fan to minimum for ASHRAE model
        this->setOnOffMassFlowRate(OnOffAirFlowRatio,
                                   0.0); // CompOnMassFlow and CompOffMassFlow are scalar, reset to this system's values
        this->calcUnitarySystemToLoad(AirLoopNum,
                                      FirstHVACIteration,
                                      0.0,
                                      0.0,
                                      OnOffAirFlowRatio,
                                      SensOutputOff,
                                      LatOutputOff,
                                      HXUnitOn,
                                      HeatCoilLoad,
                                      SupHeaterLoad,
                                      CompOn);

mjwitte commented 5 years ago

Which is why the OA system really needs to be called by the unitarysystem, but that's not an easy thing to do. If we could be sure the unitarysystem is the only thing on the branch (no other loose coils before or after), then it would be easy to solve. But leaving this general makes that more difficult. Maybe the unitarysystem needs to compare the flow rate it wants to run at with the flow rate that was set at the mixed air node and do something smart with that information.

rraustad commented 4 years ago

So with this symptom, the UnitarySystem should be in heating mode with a heating load target of load to heating set point. How to determine this symptom for cooling and heating and including the impact of OA is the key to solving this. If the mixed air temp was accurate when the decision is made it may make things easier. The PLR will change each iteration because a change in PLR will change the mixed air temp and therefore the new PLR so it may take some time to converge. Makes me think of 10x work on linearizing HVAC models to eliminate model iterations.

mjwitte commented 4 years ago

Makes me think of finding a way to let the unitary system control the OA. Options: 1) Add an OA inlet node to the unitarysystem object and bypass the whole OA-system-on-the-branch construct. 2) Add references to an OA mixer and OA controller to unitarysystem so it can call them directly 3) Locate the upstream OA system behind the scenes and call it from unitarysystem as part of the control sequence to query various mixed air temps at different flow rates (and likely different target mixed air temps). 4) ?

rraustad commented 2 years ago

This issue still exists in V9.6. However, calling ManageOutsideAirSystem only during FirstHVACIteration has an improvement on results. Max iteration warnings reduced but not eliminated.

        if (AirLoopNum > 0 && this->m_OASysNum > 0 && FirstHVACIteration) {
            state.dataLoopNodes->Node(this->m_OAMixerReturnNodeNum).MassFlowRate = state.dataLoopNodes->Node(this->AirInNode).MassFlowRate;
            MixedAir::ManageOutsideAirSystem(state, compName, FirstHVACIteration, AirLoopNum, this->m_OASysNum);
        }

NREL / EnergyPlus