-
Notifications
You must be signed in to change notification settings - Fork 397
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
Conversation
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.
@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). |
src/EnergyPlus/UnitVentilator.cc
Outdated
// 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)); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Here's my test file. Look at Unit Ventilator 1, columns BM:BN and CW:CX on 04/10 and 04/11. |
@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? |
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.
@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. |
@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? |
@mjwitte Here is the section of code that I think addresses your question:
This is done every timestep in InitUnitVentilator. Does that answer your question fully? |
@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 |
MJW requested on more change. This mod addresses that request.
@mjwitte Ok, I changed that line and made another commit. Hopefully the CI comes back clean and this is now ready to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Review Checklist
This will not be exhaustively relevant to every PR.