Menu
▾
▴
#573 E+ Bug: ChW primary pump control for Pri/Sec systems
Accepted
None
Defect
EnergyPlus
Low
CBECC-Com Repo
2019-04-18
2014-05-23
No
Originally created by: da...@360-analytics.com
Originally owned by: kbe... (code.google.com)@gmail.com
This is a new issue to cover the item noted in Issue 460, Comment # 13:
One other observation in this model: There are two chillers, each with constant speed primary ChW pumps. Chiller 2 operates much fewer hours than Chiller 1, yet the pumps for each chiller operate the same number of hours, as evidenced in image 5 and 6.
I will confirm that this is indeed still and issue and follow-up with a test model that illustrates it.
Related
Discussion
Originally posted by: kbe... (code.google.com)@gmail.com
I submit the following images as evidence that at least the 040012-OffLrg-CECStd - ap model is not running the pump while chiller 2 is inactive. Do you buy that?
Originally posted by: da...@360-analytics.com
I think it must have something to do with using a pri/sec pumping configuration; try the attached file for an example.
Status: Discussion
Originally posted by: kbe... (code.google.com)@gmail.com
Definitely still a problem in the primary / secondary systems. Seems like a bug in EnergyPlus to me. I'm consulting with E+ developer.
Originally posted by: kbe... (code.google.com)@gmail.com
A bug has been confirmed in EnergyPlus with an issue submitted here:
https://github.com/NREL/EnergyPlusTeam/issues/3522#issuecomment-51347468
I know you don't have access to this repository so here is the response from Edwin:
OK, so this isn't fixed yet. Gah.
<<<<<<<<<<<
Problem
A file from @kbenne, with common pipe and constant speed supply branch pumps was showing the second supply branch running even when it wasn't needed. It looks like the bookkeeping goes well within PlantLoopSolver::SetupLoopFlowRequest.
The demand side has a flow request of only 4 kg/s.
Each chiller branch is capable of like 50 kg/s. The supply side needy-if-on request is then about 100 kg/s.
Then, after the loopsides are swept to calculate their flow requests, a final flow request is calculated. Because there is a non-zero need-and-turn-on flow request on at least one side (the demand side), the flow request is calculated as the max of the two sides.
This inevitably turns on both pumps.
Even though this is a common pipe file, this makes sense because if we didn't, the demand side would keep running getting hotter and hotter, and the flow would all go down the common pipe. So the issue isn't that the pumps should only respond to supply requests.
Possible Solutions
It is possible with the current code and inputs that we could be more precise about what we turn on. In this case, we only need 4 kg/s, so we really should only turn on one chiller. However, we don't know that for sure, because we aren't talking load distribution yet. We could hack it in so that it only turns on 1-n branches until the n'th branch meets the flow request. But even though the flow request is low, we may actually need both chillers to meet the load (heat transfer) needs. This could be investigated within the scope of a bug fix.
It is possible we could go one step farther and add an input for determining flow distribution logic. Perhaps a set of keys such as "AllOn" or "Sequential". This would only be used on loop sides with branch pumps, probably only constant speed, and would be used only when the demand side flow (needy-and-turn-on) request is less than the supply side (needy-and-turn-on) request. That is the situation of this example file. This is on the border of bug fix / new feature...probably more toward new feature.
The next possible solution would probably require major surgery within the plant. Restructuring the plant so that it doesn't fixate on this overall loop flow request so early, instead using it as a predicted value, and then in the flow-locked (corrector) step, re-do the loop flow request calculation with information about load dispatch being included. This would be much heavier lift than a bug fix.
>>>>>>>>>>
Originally posted by: da...@360-analytics.com
Thanks for this Kyle. Is there expected to be a bug fix release for E+ before 9.0 comes out?
Originally posted by: kbe... (code.google.com)@gmail.com
There is going to be a fall "release" called 8.2.0, but it is going to be a developer focused released. It is not even clear to me if it will be posted publicly at energyplus.gov. It is C++ based, and I expect the fix will be done by then. Edwin Lee here at NREL and I are working on it.
Originally posted by: rhedr...@archenergy.com
I modified the 040112-OffLrg-VAVPriSec by removing the pumps from the chiller branches and and adding a variable speed pump on the CHW primary return branch. I plotted the cooling electric and pump electric, and it doesn't look like this solved the problem. This is all pumps, but with the cooling loads shown, I'd expect that most of the pumping is CHW.
For full discussion please click on link below:
https://sourceforge.net/p/cbecc-com/gc-issues/573/
Implement a warning for the 2016 release
Diff:
Looks like this issue is still on the E+ team's list of known issues, and is currently assigned a milestone of v8.4
https://github.com/NREL/EnergyPlus/issues/3522
There is a related issue,
https://github.com/NREL/EnergyPlus/issues/4845
but I believe if constant flow pumps on branch of primary loop (of pri/sec system) DOES work, then we are OK. Sounds like the documentation just needs to be updated.
I've confirmed this is still an issue in E+ v8.3. Attached is an example model.
A log file Warning message to notify users of this issue was added @ r3574.
No recent testing of E+ v8.4 to see if this bug still exists. Leaving issue open, changing priority to Low.
In testing this issue in EPv9.0 for the 2019RC release, we found that that there has been E+ dev work in this area:
6493 : An Intermediate Fix for Constant Speed Branch Pumps and Refactor
6523 : Continuation of Constant Speed Branch Pump Fixes
On the CBECC side, we have other related tickets
1394 - E+ Issue Branch pumps are not always off when they should be
1426 - CBECC-Com Issue - E+ Bug ChW primary pump control for Pri/Sec systems
To summarize, the issue was that all (constant speed) primary pumps would run if there was any secondary loop demand, even if only one chiller or boiler was required. After reviewing the hourly results, it appears this update fixed the pump control. However, Jireh and I found other inconsistencies that don't make sense:
a) The Plant Supply Side Demand Cooling Rate is 0 when there are cooling coils on the loop that are calling for cooling, and then in many hours the load is very high, much higher than the attached coil demand. The increase in plant demand correlates with secondary pump flow, but it is not clear what is driving the secondary pump flow; it does not appear to correlate well to the coil load.
b) There are times when the Plant Supply Side Demand Cooling Rate is 0, and the chillers are off, but there is a cooling coil demand, and the Plant Supply Side Inlet/Outlet delta T is non-zero, reflecting some amount of "free" cooling.
These issues were identified on the ChW system but I see similar issues on the HW system if it is set up in a similar pri/sec configuration with branch pumps.
Attached is a new example model that I created for testing; the other model we sent Kyle had more systems and other varying control issues that I was concerned might be complicating the control. Below is a picture illustrating what I describe above for the HVAC Timestep scale for 1 day.
Last edit: David Reddy 2019-04-11
CHECKSIM Warning added @ r5856 of 2019-1-0_RC-DRDev branch to inform users Pri/Sec configuration results in unexpected plant simulation behavior.
From KB 3/28/19:
Hi Everyone,
I don’t have concrete feedback from Edwin, but I did some research on this myself. The attached file shows all of the commits to the PlantLoop code (does not include changes to plant components) btween 8.5.0 and 9.0.0.
There are a few interesting commits worth calling out. Sorry I cannot boil this down to specific action items yet, but you might still find this informative.
https://github.com/NREL/EnergyPlus/commit/45e360f9d278b3b74f09765b6d01e3aea27f97e0
https://github.com/NREL/EnergyPlus/commit/b9878fd66ca9664ab70414a6c6835eba838b66c7
https://github.com/NREL/EnergyPlus/commit/9387f4ae1fc1c1df5d6c4b8e71c7d20692b1d8cc