SetpointManager:SingleZone:Reheat sets supply temp incorrectly for some cases

[mjwitte]

Defect file is a quick service restaurant with high ventilation rates. The kitchen PSZ system with central cooling and heating coils controlled by SepointManager:SingleZone:Reheat is requesting heat at times when it should be allowing the zone to float down to the heating setpoint. This results in significant excess heating coil operation. The setpoint manager has complex logic to determine what to do when the zone thermostat signals that it is in the deadband, so it should be letting the zone float down.

The defect file has EMS programs that adjust the economizer and OA settings, so the problem is likely due to the SZRH setpooint manager's internal calculations which try to estimate the supply temp with no coil operation and min OA fraction.

[mjwitte]

@EnergyArchmage Even without EMS, the approach used in SetpointManager:SingleZone:Reheat to estimate the mixed air temperature and use that as a supply air setpoint is risky. Seems that is should be able to simply look at the load to cooling setpoint and load to heating setpoint and choose based on that. if I were to rethink this from scratch, I'd be inclined to have this calculate two setpoints - one for heating and one for cooling and make the controllers able to honor the appropriate one. But that's too much change for now.

[EnergyArchmage]

I cannot find the defect file for this in dev support.

[mjwitte]

@EnergyArchmage Arrrgh. Not sure if these were the intended files, but these should work. Look at the heating coil gas use on System 2 on March 19 for one example.

[EnergyArchmage]

I am starting to work on this one, created pivotal ticket and branch 4967-SZRH-spm

[EnergyArchmage]

Okay, I have evaluated a change to use the current OA fraction instead of the minimum OA fraction in the algorithm. This change appears to do what is desired by this issue. That is it generally leads to lower coil use when the actual OA rate is different than the minimum OA.

However, in some test files there is an energy increase, so it is not a clear cut case of this change always working out to save energy. Many test files run about the same in terms of energy. It is hard to say the change here is better, just different. The large increases in energy are in cases where the single zone reheat manager is just used for mixed air node and economizer control and there is separate unitary system doing relative humidity control; the change can lead to more agressive economizer action and more reheat coil activity for humidity control, eg. FurnaceWithDXSystemRHcontrol the annual increase in heating energy is 10%.

The heating savings in the defect file is 40%, so that is substantial and I think it does make sense to go ahead and adopt this change to single zone reheat setpoint manager.

[mjwitte]

@EnergyArchmage Is the current OA fraction lagged from the end of the previous timestep (I don't remember if this setpoinmanager is only called at the beginning of the timestep). Seems that this could get into a feedback loop with the economizer or kind of force what the economizer does because the economizer is going to try to modulate to meet this setpoint.

[EnergyArchmage]

Yes, the OA fraction (and the minimum OA fraction before) are from the end of the previous timestep. The setpoint manager does run before the outside air system is called. Yes there is economizer interaction and it was already present, but I don't think it is unstable because the setpoint manager does not get called again.

The largest differences in operation are observed when the OA is getting increased over minimum to serve zone exhaust fans, not really for economizing.

[mjwitte]

This may be all we can do for now. It's just problematic to force a setpoint that may require some heating or cooling coil operation when it should be floating. At some point we need to move towards something better like hi/lo setpoints on single duct systems.

[mjwitte]

@EnergyArchmage For the unitary system example files that are using the SetpointManager:SingleZoneReheat only to give the economizer a setpoint, would you agree that changing them to use SetpointManager:SingleZoneCooling would be more appropriate?

[EnergyArchmage]

It is an interesting idea, but I think it would take some study. I suspect it might increase heating energy.

[mjwitte]

Changing to SetpointManager:SingleZoneCooling looks good for cases where the SZRH manager is only controlling the mixed air temperature. But there aren't many like that. There are many which are controlling individual cooling and heating coils (these really need to be split out into two setpoint managers).

Tested FurnaceWithDXSystemRHcontrol as an annual simulation with both flavors of setpoint manager. Old SZReheat manager, Cooling = 39.14GJ, Heating = 163.59GJ New SZReheat manager, Cooling = 44.61, Heating = 180.38 SZCooling manager, Cooling = 36.56, Heating = 155.98

And one with economizer but no RH control, HVACTemplate-5ZoneFurnaceDX (again as annual): Old SZRheat manager, Cooling = 22.40, 40.76 New SZReheat manager, Cooling = 22.37, 40.87 SZCooling manager, Cooling = 22.40, Heating = 40.64

[mjwitte]

Closed via #5202