VSP Target Pressure - Pump Output Higher

Question

The VSP's in my system do not reduce speed to meet the target head assigned. I have a large model with many facilities, including 7 ON constant speed pumps, 7 VSP pumps, and 4 VSP Batteries. 
 Some of the variable speed pumps/batteries reduce speed to meet the input target head, and some do not. In previous versions of the model all pumps functioned as expected. The conversion of some VSP's to VSPB's seemed to cause some un-modified VSP's to have trouble converging. 
 
 Are there any known data input situations where this could occur? How should I go about troubleshooting if the model does not seem to obey input data? 
 
 Thanks for any guidance.

Jesse Dringoli · Answer

Hello Andrew, 
 
VSPBs assume that a single pump in the battery turns on first and attempts to meet the target. A second, "lag" pump only turns on if the first pump cannot meet the target within the maximum relative speed factor. A third lag pump turns on if the first two together cannot meet the target within the maximum relative speed factor, and so forth. 
 
When you say that some VSPBs do not reduce speed to meet the target head, are you saying that the HGL at the target node is above the target HGL and the VSPB is operating at 1.00 relative speed factor? Is it possible that a reduction in the pump speed may not be able to cause a drop in HGL at the target node down to the target value? For example if something else downstream is causing the HGL to remain higher than the target even with the pump off. 
 
When you converted the parallel VSPs into a single VSPB, did you ensure the settings were correctly entered? Was there significant headloss in the parallel piping of the regular VSP nodes that may not be reflected in the VSPB case? 
 
In general, you want to make sure that the VSPBs have direct influence on the target node and that you don't have multiple VSPBs discharging into the same pressure some. If you have a complex model setup with logic set up too "tight", it cane become sensitive, to the point where a small change can cause relatively large changes in the results. You may want to take a close look at the Calculation Summary to see if any timesteps are unbalanced, if any use an excessive number of trials to converge and if there are any important clues in the messages tabs at the bottom such as Intra-Trial Status Messages. 
 
If this does not help, please provide your WaterGEMS/WaterCAD version number and a copy of the model file along with steps to observe the problem. You can find the version under Help > About, in the lower left corner within brackets. The latest is 08.11.06.113. There are two options for sharing your model on Communities. Either way, be sure to zip your files first. The first option is to attach to your reply on the forum using the Advanced Reply Editor (see link below and to the right of the reply box). If your data is confidential, use the instructions in the link below to send it via Bentley Sharefile. Files uploaded to Sharefile can only be viewed by Bentley. 
 
 communities.bentley.com/.../7079.be-communities-secure-file-upload

Jesse Dringoli · Answer

I've taken a deep look at your model using the same version you have and found that part of the problem does appear to involve the multiple VSPs and VSPBs discharging to the same pressure zone, but there are other factors as well. Below I've listed some of the areas that have problems: 
 1) "Devon Manor" and "US Steel" are both VSPs with different target HGL and discharge into zone "D-2", but they currently turn on at different times. The reason why they appear to operate at full speed with the target node's HGL higher than the setting is because if they try to ramp down their speed, the other pumps and the tank in this zone provide enough head to maintain the target HGL at the target node. Therefore they go into "fixed speed override" and operate at full speed. For example if you perform a steady state simulation with "Is Variable Speed Pump?" set to "False" for pump "US Steel" and set the relative speed factor to 0.7, you'll see that the pump cannot pass any flow and the HGL at the target node is already higher than the target HGL, because of the head provided by other elements in the model. For example create a profile between that pump and tank "Parkway West", which is at 657 ft (compared to the target of 605). I also noticed that there appears to be a path between the zones marked as D-2 and D-3, through "Copperstone FCV". Even though the setting is only 30 gpm, there might be a significant amount of head added by pump "Hummelstown Hi HSP #3" that can makes its way through this FCV. 
 Also, VSPB "East Park Dr" discharges out of this pressure zone and is on at the same time as the other two, which could possibly lead to similar stability issues (where "Devon Manor" and "US Steel" aren't the only influence on the HGL at their target nodes). 
 2) "East Park Dr" and "Hummelstown Hi HSP #3" are both VSPs with different target HGL, and are seen on at the same time and discharge into zone "D-3". "East Park Dr" has a HGL target of 613 ft whereas "Hummelstown Hi HSP #3" has a target of 720 ft. The numerical solver was not designed to work in this configuration, which is part of why you're encountering problems with these particular pumps. Here is a related article on this subject: 
 http://communities.bentley.com/products/hydraulics___hydrology/w/hydraulics_and_hydrology__wiki/10118.vsp-or-vspb-not-properly-maintaining-target-hgl 
 3) The reporting timestep is set to 1 hr, so you will miss details between timesteps in graphs. I suggest setting this to "all" for troubleshooting. 
 4) Three tanks become full during the simulation, which engages an automatic altitude valve that closes the adjacent pipe, which can cause issues and disconnections. These tanks do not appear to have any controls set to prevent this from happening. Offending tanks: &ldquo;Oberlin&rdquo;, &ldquo;chambers hill reservoir&rdquo;, &ldquo;spring garden&rdquo; 
 5) There are appear to be other missing controls and settings: - PRV "Pennswood" is set to active with a pressure setting of zero. If this should be closed (as the Notes seem to indicate), it would be best to set the initial status to Closed. - PSV "US Steel PSV", "Devon Manor PSV", "Colorado PSV" and "Locust Lane PSV" have controls to close, but no control to reopen. - there is a control set to turn off "Blue Meadows #2" based on tank "Blue Meadows", but no control to turn the pump back on. - there may be other similar issues 
 6) The slowdown in calculation progress is a clear indicator of stability problems. The model has a difficult time converging on a balanced solution and requires additional timesteps. A good tool to help with this is the Intra-Trial Status Messages tab in the calculation summary. This can give you clues as to what the model is having trouble with. In your model, for the timesteps that see excessive timesteps (greater than ~40), I observe dozens, in some cases hundreds of intra-trial status messages. The elements that show up here multiple times, switching back and forth between status, indicate that they are "fighting" against other elements and should be investigated. Many of your PRVs, PSVs, pumps and check valve show up. 
 7) There are several areas that have two PRVs in parallel, which can be difficult to solve. For example Latsha 6" and Latsha 2". It is suggested that you combine these into a single PRV, to reduce calculation complexity. See below article: 
 http://communities.bentley.com/products/hydraulics___hydrology/w/hydraulics_and_hydrology__wiki/18158.i-have-prv-s-in-parallel-that-are-both-open-at-the-same-time-and-when-i-go-to-compute-my-model-i-get-a-user-notification-that-says-network-unbalanced-how-do-i-resolve-this 
 With that said, I realize that this is not necessarily a complete solution, but rather a list of things that appear to need attention. Once you've had a look at these and implement any necessary changes on your end (you may need to use your own judgment for this, given the assumptions presented), I'd be happy to meet with you to discuss further.