Controller:OutdoorAir "Heat Recovery Bypass Control Type" causing erratic oa rates

[kbenne]

An example file and graphs will be uploaded to demonstrate this issue. A value of "BypassWhenOAFlowGreaterThanMinimum" in Controller:OutdoorAir "Heat Recovery Bypass Control Type" will produce very unusual results. Generally, OA rates are found running way above spec, forcing fan to run at full capacity. In some cases very large discrepancies between supply outlet node flow rate and demand inlet node flow rate. Using a value of "BypassWhenWithinEconomizerLimits" corrects the issue. This can be demonstrated in models that don't even have heat recovery devices on the oa system.

[kbenne]

I'm not going to upload a defect file unless someone requests it. The issue can be demonstrated by just replacing the OA controller object in the 5ZoneAirCooled.idf example file with the following:

  Controller:OutdoorAir,
    OA Controller 1,         !- Name
    Relief Air Outlet Node 1,!- Relief Air Outlet Node Name
    VAV Sys 1 Inlet Node,    !- Return Air Node Name
    Mixed Air Node 1,        !- Mixed Air Node Name
    Outside Air Inlet Node 1,!- Actuator Node Name
    1.04982,                !- Minimum Outdoor Air Flow Rate {m3/s}
    1.04982,                !- Maximum Outdoor Air Flow Rate {m3/s}
    NoEconomizer,            !- Economizer Control Type
    ModulateFlow,            !- Economizer Control Action Type
    19.,                     !- Economizer Maximum Limit Dry-Bulb Temperature {C}
    ,                        !- Economizer Maximum Limit Enthalpy {J/kg}
    ,                        !- Economizer Maximum Limit Dewpoint Temperature {C}
    ,                        !- Electronic Enthalpy Limit Curve Name
    4.6,                     !- Economizer Minimum Limit Dry-Bulb Temperature {C}
    NoLockout,               !- Lockout Type
    ProportionalMinimum,            !- Minimum Limit Type
    ,            !- Minimum Outdoor Air Schedule Name
    ,                                       !- Minimum Fraction of Outdoor Air Schedule Name
    ,                      !- Maximum Fraction of Outdoor Air Schedule Name
    , !- Mechanical Ventilation Controller Name
    ,                                       !- Time of Day Economizer Control Schedule Name
    No,                                     !- High Humidity Control
    ,                                       !- Humidistat Control Zone Name
    ,                                       !- High Humidity Outdoor Air Flow Ratio
    Yes,                                    !- Control High Indoor Humidity Based on Outdoor Humidity Ratio
    BypassWhenOAFlowGreaterThanMinimum;       !- Heat Recovery Bypass Control Type

The key change is the addition of the last field with value "BypassWhenOAFlowGreaterThanMinimum"

Here are the incorrect oa rates we see:

Here is what we expect when the example file runs normally:

The issue seems to be emphasized in during heating hours.

[mjwitte]

Helpdesk ticket 10673
User: I've attached 2 IDF files. They're identical with the exception of 'Heat Recovery Bypass Control' input in the controller:OutdoorAir. Neither of these have a heat exchanger or economizer. From what I understand from the I/O reference, this input then shouldn't have any impact on the energy use of a building. However, the heating energy use is ~75% lower when the bypass control is specified as 'BypassWhenOAFlowGreaterThanMinimum'.

These files have been added as defect files. Upping the priority on this.

[rraustad]

At around line 4190 in MixedAir.cc there is a test. I suspect this test occurs whether or not a HX exists.

// set the air loop economizer and high humidity control flags.
if ( EconomizerOperationFlag ) {
if ( OAController( OAControllerNum ).HeatRecoveryBypassControlType == BypassWhenOAFlowGreaterThanMinimum ) {

// Optional heat recovery bypass control flag uses additional logic to allow ERV optimization
if ( AirLoopControlInfo( AirLoopNum ).CheckHeatRecoveryBypassStatus && AirLoopControlInfo( AirLoopNum ).OASysComponentsSimulated ) {

I can think of 2 ways to fix this. 1) check for HX and if not present flip the HeatRecoveryBypassControl type back to default, or 2) include a HXPresent flag in this IF test.

[mjwitte]

@rraustad If there is no HX present, then it shouldn't matter what the bypass status is set to. Why does this test change anything? It should simply set a flag that gets ignored because there is no HX to look at it.

[rraustad]

I agree with you it should be ignored, but it appears it's not ignored (so I would look here first).

At line 4213:
if ( MixedAirTempAtMinOAFlow <= Node( OAController( OAControllerNum ).MixNode ).TempSetPoint ) {

AirLoopControlInfo( AirLoopNum ).EconomizerFlowLocked = true;

then at line 4236:
if ( AirLoopControlInfo( AirLoopNum ).EconomizerFlowLocked ) {
OAController( OAControllerNum ).OAMassFlow = AirLoopFlow( AirLoopNum ).MinOutAir;
}

I still think my suggestion above would fix this, but it's still a guess until it's tested.

[rraustad]

There is already a way to check for a OAHX, still TBD whether that flag can be used for this fix.

        SimOAComponent( CompType, CompName, OutsideAirSys( OASysNum ).ComponentType_Num( CompNum ), FirstHVACIteration, OutsideAirSys( OASysNum ).ComponentIndex( CompNum ), AirLoopNum, Sim, OASysNum, OAHeatCoil, OACoolCoil, OAHX );
        if ( OAHX ) ReSim = true;

[mjwitte]

@rraustad I still contend this should not be necessary. Something else somewhere is misusing the bypass flag.

[mjwitte]

Defect files have been added. There is more going on than just the Heat Recovery Bypass Control Type Field. For 5ZoneAirCooled, I could not reproduce the problem without using the exact Controller:OutdoorAir object shown above (from @kbenne ).

For the user files (check the flow at "Node 47") I did make a variant which removes Controller:MechanicalVentilation for the first system, and the problem still shows. I suspect some of the other economizer limit fields may be impacting this (which would be why I couldn't reproduce it with plain vanilla 5ZoneAirCooled).

For the user files, BypassWhenOAFlowGreaterThanMinimum gives the correct OA flow at Node 47 (0.54899 is the autosized min OA flow rate) while BypassWhenWithinEconomizerLimits give the wrong OA flow rate (0.3271). Note that both files always report zero for Economizer Status and Heat Recovery Bypass Status.

[MatthewSteen]

+1

[mjwitte]

@kbenne @Myoldmopar @rraustad @wfbuhl
Running 5ZoneAirCooled-BypassWhenOAFlowGreaterThanMinimum-PerKB defect which has no heat exchanger, no economizer, NoLockout, and ProportionalMinimum. Note that both Max and Min Outdoor Air Flow Rates are both set to 1.04982 (this is a contributing factor).

Right out of the gate, it's landing in this block of code:

            if ( AirLoopControlInfo( AirLoopNum ).HeatingActiveFlag && OAController( OAControllerNum ).HeatRecoveryBypassControlType == BypassWhenOAFlowGreaterThanMinimum ) {
                AirLoopControlInfo( AirLoopNum ).HeatRecoveryBypass = false;
                OAController( OAControllerNum ).HeatRecoveryBypassStatus = 0;
                OAController( OAControllerNum ).HRHeatingCoilActive = 1;
                // reset the OA flow to minimum
                OAController( OAControllerNum ).OAMassFlow = AirLoopFlow( AirLoopNum ).MinOutAir;
                AirLoopFlow( AirLoopNum ).OAFrac = OAController( OAControllerNum ).OAMassFlow / OAController( OAControllerNum ).MixMassFlow;
                AirLoopFlow( AirLoopNum ).OAMinFrac = AirLoopFlow( AirLoopNum ).OAFrac;

1. This looks like the heating economizer lockout - should be checking for LockOutWithHeating rather than BypassWhenOAFlowGreaterThanMinimum.
2. At this point, AirLoopFlow(1) looks like this. Note the supply and return flows are 0.37, but MinOutAir is 1.23. So OAMassFlow gets set to 1.23 - which somehow later is trying for force the supply flow back up to 1.23 resulting in max iteration problems.
   
3. *MinOutAir should never be > the current supply flow, should it?
   I guess that depends on how MinOutAir will be used, especially in this case where the Min OA flow rate is fixed at the design supply flow rate in a VAV system (which isn't really valid) but the same condition could occur if, say, a DCV controller asked for more OA than the current supply flow - in that case who should rule?
4. There are times where users would like the OA requirement to override the supply air flow rate, but it's not supposed to be happening at this point. I/O Ref description for the OA controller is not clear about this, and the Engineering Ref just tosses this in at the end in a list of constraints.
   
   Will need to track down where the OA controller is messing with the mixed air flow rate.

Stay tuned . . .

[mjwitte]

This BypassWhenOAFlowGreaterThanMinimum section of code was introduced initially for CR9030 / #3803 with this commit

And then modified for CR9054 / #3826 with this commit

[rraustad]

The point here was to use the minimum OA flow rate if the heating coil
was active (found on first pass through then used during the second
iteration) when using BypassWhenOAFlowGreaterThanMinimum. This had
nothing to do with LockOutWithHeating back when this was added. Not to
say is shouldn't have checked, but the user specifically requested that
the HX not bypass when the heating coil was active (to minimize
heating), and if so, then reset the flow rate back to the minimum (so
the HX could stay on ... HeatRecoveryBypass = false). This was long ago
so maybe some of the facts are blurred. I worked days on this and
finally the user was happy with the result. When he gave his approval, I
stopped messing with the logic.

IDD:
\note BypassWhenOAFlowGreaterThanMinimum specifies enhanced
economizer
\note controls to allow heat recovery when economizer is active
\note (within limits) but the outdoor air flow rate is at the
minimum.

Maybe that line should also check for SA flow rate to see which is
lower? And why was the supply air flow rate lower than the minimum OA
flow rate? I guess the VAV boxes don't know of the OA minimum? And
OAFrac was > 1 here (what does that mean)?

I wouldn't think it would hurt to use|(the point was just to go to a
minimum):||

OAController( OAControllerNum ).OAMassFlow = min( SAFlow, AirLoopFlow(
AirLoopNum ).MinOutAir ); |

I would check where the OA flow is capped by the minimum to see where
this code is relative to that code.

This falls into the issue of locking down the OA controller when some
decision is made. I've been thinking about this lately. These max
iterations have made me question whether this is being done correctly
(here and elsewhere).

On 9/9/2015 10:06 AM, Michael J. Witte wrote:

@kbenne https://github.com/kbenne @Myoldmopar
https://github.com/Myoldmopar @rraustad
https://github.com/rraustad @wfbuhl https://github.com/wfbuhl
Running 5ZoneAirCooled-BypassWhenOAFlowGreaterThanMinimum-PerKB defect
which has no heat exchanger, no economizer, NoLockout, and
ProportionalMinimum. /Note that both Max and Min Outdoor Air Flow
Rates are both set to 1.04982 (this is a contributing factor)/.

Right out of the gate, it's landing in this block of code
https://github.com/NREL/EnergyPlus/blob/develop/src/EnergyPlus/MixedAir.cc#L4354-L4362:

|if ( AirLoopControlInfo( AirLoopNum ).HeatingActiveFlag &&
OAController( OAControllerNum ).HeatRecoveryBypassControlType ==
BypassWhenOAFlowGreaterThanMinimum ) { AirLoopControlInfo( AirLoopNum
).HeatRecoveryBypass = false; OAController( OAControllerNum
).HeatRecoveryBypassStatus = 0; OAController( OAControllerNum
).HRHeatingCoilActive = 1; // reset the OA flow to minimum
OAController( OAControllerNum ).OAMassFlow = AirLoopFlow( AirLoopNum
).MinOutAir; AirLoopFlow( AirLoopNum ).OAFrac = OAController(
OAControllerNum ).OAMassFlow / OAController( OAControllerNum
).MixMassFlow; AirLoopFlow( AirLoopNum ).OAMinFrac = AirLoopFlow(
AirLoopNum ).OAFrac; |

1. This looks like the heating economizer lockout - should be
   checking for LockOutWithHeating rather than
   BypassWhenOAFlowGreaterThanMinimum.
2. At this point, AirLoopFlow(1) looks like this. /Note the supply
   and return flows are 0.37, but MinOutAir is 1.23./ So OAMassFlow
   gets set to 1.23 - which somehow later is trying for force the
   supply flow back up to 1.23 resulting in max iteration problems.
   image
   https://cloud.githubusercontent.com/assets/4991075/9762823/7db1624c-56cb-11e5-9387-bceebe4c9541.png
3. *MinOutAir should never be > the current supply flow, should it? I
   guess that depends on how MinOutAir will be used, especially in
   this case where the Min OA flow rate is fixed at the design supply
   flow rate in a VAV system (which isn't really valid) but the same
   condition could occur if, say, a DCV controller asked for more OA
   than the current supply flow - in that case who should rule?
4. There are times where users would like the OA requirement to
   override the supply air flow rate, but it's not supposed to be
   happening at this point. I/O Ref description for the OA controller
   is not clear about this, and the Engineering Ref just tosses this
   in at the end in a list of constraints. image
   https://cloud.githubusercontent.com/assets/4991075/9763632/41ad4cb6-56d0-11e5-97ed-906b6183fe7d.png
   Will need to track down where the OA controller is messing with
   the mixed air flow rate.

Stay tuned . . .

—
Reply to this email directly or view it on GitHub
#4568 (comment).

Richard Raustad
Florida Solar Energy Center
1679 Clearlake Road
Cocoa, FL 32922
Ph: (321)638-1454
http://www.fsec.ucf.edu/en/

Program Director
Electric Vehicle Transportation Center
http://evtc.fsec.ucf.edu/

[mjwitte]

@rraustad But this isn't testing if OAflow is > minimum anymore. And BypassWhenOAFlowGreaterThanMinimum should only touch the HX bypass flag, and it should only take action when OAflow is > minimum. So resetting OA flow to minimum based on this flag seems wrong.

My simple mind says the economizer should make it's decision about OA flow rate regardless of the HX bypass option (which I think it is already doing).

Then Heat Recovery Bypass Control Type option should set the bypass flag true if within economizer limits (BypassWhenWithinEconomizerLimits) or OA flow > min (BypassWhenOAFlowGreaterThanMinimum). Nothing more. It shouldn't touch any flow rates.

So, I need to look back at the original problem that prompted this code and see where the disconnect is.

[rraustad]

On 9/9/2015 11:04 AM, Michael J. Witte wrote:

@rraustad https://github.com/rraustad But this isn't testing if
OAflow is > minimum anymore.

Correct, it just senses the heating coil activity and resets flow to
minimum. The OA flow should not be above the minimum if the heating coil
is active, that is no longer an economizer and would just waste energy.

And BypassWhenOAFlowGreaterThanMinimum should only touch the HX bypass
flag, and it should only take action when OAflow /is/ > minimum. So
resetting OA flow to minimum based on this flag seems wrong.

Hard to disagree with that unless the flag name is misleading (what if
it were OptimizeEconomizerAndHXOperation). There is also other logic
there that looks at a calculated mixed air temperature, and if
conditions are right, will allow the HX to turn on if it calculates that
the heating coil would turn on. See line 4306
if ( OAController( OAControllerNum
).HeatRecoveryBypassControlType == BypassWhenOAFlowGreaterThanMinimum ) {
// Optional heat recovery bypass control flag uses
additional logic to allow ERV optimization

There is also another OAMassFlow = MinOutAir line of code in there.

My simple mind says the economizer should make it's decision about OA
flow rate regardless of the HX bypass option (which I think it is
already doing).

I'm not saying there is no possibility of a logic mistake. It's just
that in this case the SA flow is lower than the minimum, which wasn't
expected. And that this was working very well for the original defect
file (both the user and I agreed, I can't recall if you reviewed).

Then Heat Recovery Bypass Control Type option should set the bypass
flag true if within economizer limits (BypassWhenWithinEconomizerLimits)

agreed

or OA flow > min (BypassWhenOAFlowGreaterThanMinimum). Nothing more.
It shouldn't touch any flow rates.

So if the heating coil is on and the flow > min, leave the flow alone (I
think this was the original complaint)? Maybe, but in that case
shouldn't the HX turn on to minimize heating energy (or users should be
able to optimize this themselves without logic intervention).

So, I need to look back at the original problem that prompted this
code and see where the disconnect is.

—
Reply to this email directly or view it on GitHub
#4568 (comment).

Also note the forced iteration flags at line 4363 that were added to get
this to work.

Richard Raustad
Florida Solar Energy Center
1679 Clearlake Road
Cocoa, FL 32922
Ph: (321)638-1454
http://www.fsec.ucf.edu/en/

Program Director
Electric Vehicle Transportation Center
http://evtc.fsec.ucf.edu/

[mjwitte]

Need to think through all the possibilities here. I don't disagree that the heating coil operation vs hx operation check is useful, but it should be separate - either linked LockoutWithHeating, or as you suggest, another HX bypass choice. Will chew on this a bit and propose a change.

[Myoldmopar]

@mjwitte Your commit message (c11e0d9) shows 'addresses', but your PR description in #5219 says 'partially addresses'. I'm closing this since I think your commit message is more likely to be accurate.

Closed via #5219