Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unit Ventilator Variable Fraction OA Control Correction and Fix Fan Mode Schedule with Fan:SystemModel #7386

Merged
merged 7 commits into from
Jul 29, 2019

Conversation

RKStrand
Copy link
Contributor

@RKStrand RKStrand commented Jul 12, 2019

Pull request overview

This work fixes an issue with the unit ventilator variable fraction outside air control. Previously, unit ventilator, when in cooling mode would toggle between the minOA and maxOA fraction without a cooling coil and with a cooling coil would simply default to the minOA. This does not allow appropriate variation of the OA fraction. Both the with and without cooling coil options during cooling mode have now been adjusted to allow any variation between the minOA and maxOA fraction to meet the cooling load. When the outside air temperature is above the zone return temperature, the OA fraction is still set to the minimum as before. What is new is the ability to vary the OA fraction when the outside air temperature is cooler to meet the load. Previously, it was possible to overcool the space with outside air. This addresses GitHub Issue #7285 and includes both a new unit test and modified documentation.

Also, this fixes the Supply Fan Operating Mode Schedule to work correctly with Fan:SystemModel. Previously, the fan mode was always continuous regardless of the schedule values.

Work Checklist

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

  • Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
  • At least one of the following appropriate labels must be added to this PR to be consumed into the changelog:

Review Checklist

This will not be exhaustively relevant to every PR.

  • Functional code review (it has to work!)
  • If defect, results of running current develop vs this branch should exhibit the fix
  • CI status: all green or justified
  • Performance: CI Linux results include performance check
  • Unit Test(s)
  • C++ checks:
    • Argument types
    • If any virtual classes, ensure virtual destructor included, other things
  • IDD changes n/a
  • If new idf included, locally check the err file and other outputs
  • Required documentation updates?

RKStrand added 4 commits July 11, 2019 16:15
This commit includes changes to the EnergyPlus code to address the
defect.  A subroutine was added to calculate OA Mass Flow Rate for unit
ventilators in cooling mode for Variable Percent OA control with and
without cooling coils.
Creation of a unit test to exercise the new function that was added as
part of the fix.
Documentation changes to accompany the code changes.  Variable percent
for both with and without a cooling coil while cooling agree with the
code as modified for this bug fix.  Note that above these sections in
both documents the text was wrong before but is correct now without
changes to the text because it is in line with the modified code.
@RKStrand RKStrand added Defect Includes code to repair a defect in EnergyPlus EnergyPlus labels Jul 12, 2019
@RKStrand RKStrand requested a review from mjwitte July 12, 2019 17:11
@RKStrand
Copy link
Contributor Author

@mjwitte I tagged you as a reviewer for this one since we have already had discussions about it. There are small differences in three test cases--all ones that should see changes because they have unit ventilators that use variable percent OA control (which was the focus of this work).

// First, use a simple load equals mass flow times Cp time Delta T equation to find OA Mass Flow Rate.
// Then, limit the OA Mass Flow Rate between the MinOA flow and the MaxOA flow.

ActualOAMassFlowRate = std::abs(QZnReq) / (PsyCpAirFnWTdb(DataEnvironment::OutHumRat,Toutdoor) * (Tinlet-Toutdoor));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why, but this is off by about 30W from what the cooling coil is doing. I'll attach a test idf that shows the cooling coil operating at about 30W whenever the OA flow is between min and max.
Oh - it's probably the fan heat?
Also, this probably needs to be sensitive to OpMode == CycFanCycCoil - then set to max?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mjwitte Before I make a change, what you are asking for is:

When OpMode == CycFanCycCoil, then set:

ActualOAMassFlowRate = MaxOAFrac * MassFlowRate

Correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my initial thought. I'm fairly certain that's how the airloop economizer functions with cycling fan. Otherwise, you end up with two variables - fan runtime and OA fraction to mess with to meet the load. And I would expect you want to maximize the beneficial outdoor air.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I'm not sure setting OAMassFlowRate works - You want 100% OA that cycles on enough to meet the load.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mjwitte Elsewhere in this model, I am seeing the following code:

    if (FanOpMode == CycFanCycCoil) {
        OutAirMassFlowRate = min(OAMassFlowRate, Node(InletNode).MassFlowRate);
    }

which basically limits the outside air mass flow rate if the fan is cycling if I am understanding it correctly. Do you feel if I do something similar in the new function that this will resolve the concern?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure - this has to be done at the appropriate point in the process in order for the mixing (if any) and cycling control to all work from the correct value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it seems like SimUnitVentOAMixer (which is where that reassignment that I showed in my previous comment) should be run and then it would take care of the cycling case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully, test files will tell . . .


OAMassFlowRate = SetOAMassFlowRateForCoolingVariablePercent(MinOAFrac,Node(OutsideAirNode).MassFlowRate,
GetCurrentScheduleValue(UnitVent(UnitVentNum).MaxOASchedPtr),
Tinlet,Toutdoor);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice to pull this out into a separate function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks--makes unit testing cleaner as well.

@mjwitte
Copy link
Contributor

mjwitte commented Jul 18, 2019

Here's my test file. Look at Unit Ventilator 1, columns BM:BN and CW:CX on 04/10 and 04/11.
UnitVent5ZoneAuto-Variable-MinOAOn-Annual-SelectMonths-Detailed.idf.txt

@RKStrand
Copy link
Contributor Author

@mjwitte So, looking at the test file that you supplied, what I think that I am seeing is that there is this leftover 30-ish Watt cooling coil load that hits for a while (presumably fan energy as you suggested?) and then finally the cooling coil starts actually producing some real numbers. On 4/10, it appears that before that 30W cooling coil load shows up that the system is running with min OA, meaning it has more than enough cooling to use outside air. Then, once it starts to modulate, it isn't factoring in the fan heat so the cooling coil is forced to run a small fraction. It varies the OA amount until the maximum at which point you see the cooling coil load go beyond 30W. I'm seeing the same pattern on 4/11. So, based on this, it seems like the problem here is that my new algorithm is not factoring in fan heat and this is causing some cooling coil load that isn't necessary. So, I should factor the fan heat in and this should eliminate the 30W cooling coil loads. Does this summarize the concern you had and the potential solution? Or are there more issues?

@mjwitte
Copy link
Contributor

mjwitte commented Jul 22, 2019

Yes, that summarizes it.

Testing of the pull request showed some strange situations where the
cooling coil was coming on to deal with the fan heat.  The algorithm
was modified to take fan heat into account and only run the coil when
it was really needed and to increase the OA amount to handle the load
and fan heat if possible.
@RKStrand
Copy link
Contributor Author

@mjwitte Just committed changes which address the fan heat issue and also expand the unit test cases from 4-7 to test the modified code. This should be ready for re-review when the CI machines finish doing their thing.

@mjwitte
Copy link
Contributor

mjwitte commented Jul 26, 2019

@RKStrand The results for UnitVent5ZoneAuto-Variable-MinOAOn-Annual-SelectMonths-Detailed.idf.txt look good now. I tried a variation on this with the Unit Ventilator 1 Supply Fan Operating Mode Schedule set to always = 0 to test cycling fan operation and the results are identical to the continuous fan case. If I leave the fan operating mode schedule blank, then I get cycling fan operation and the control looks good. Can you check if the fan mode schedule is being used correctly to switch the fan mode every timestep?

@RKStrand
Copy link
Contributor Author

@mjwitte Here is the section of code that I think addresses your question:

    if (UnitVent(UnitVentNum).FanSchedPtr > 0) {
        if (GetCurrentScheduleValue(UnitVent(UnitVentNum).FanSchedPtr) == 0.0 && UnitVent(UnitVentNum).FanType_Num == FanType_SimpleOnOff) {
            UnitVent(UnitVentNum).OpMode = CycFanCycCoil;
        } else {
            UnitVent(UnitVentNum).OpMode = ContFanCycCoil;
        }
    }

This is done every timestep in InitUnitVentilator. Does that answer your question fully?

@mjwitte
Copy link
Contributor

mjwitte commented Jul 29, 2019

@RKStrand The fan type in the test file is Fan:SystemModel. This fan cycling if wasn't modified to allow to that fan type. Since the input processing checks for illegal combination of fan and cycling schedule, I would just remove the && UnitVent(UnitVentNum).FanType_Num == FanType_SimpleOnOff here.

MJW requested on more change.  This mod addresses that request.
@RKStrand
Copy link
Contributor Author

@mjwitte Ok, I changed that line and made another commit. Hopefully the CI comes back clean and this is now ready to go.

@mjwitte mjwitte changed the title Unit Ventilator Variable Fraction OA Control Correction Unit Ventilator Variable Fraction OA Control Correction and Fix Fan Mode Schedule with Fan:SystemModel Jul 29, 2019
Copy link
Contributor

@mjwitte mjwitte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RKStrand Tested the fan operating mode schedule fix - all looks good now.
Discovered a new problem while reviewing the cycling fan results, see #7420.

@mjwitte mjwitte merged commit 4f4f5d8 into develop Jul 29, 2019
@mjwitte mjwitte deleted the 7285-UnitVentControlProblem branch July 29, 2019 19:45
@mjwitte mjwitte mentioned this pull request Aug 5, 2019
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Defect Includes code to repair a defect in EnergyPlus
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants