Darwin designer is not at all optimizing...

Question

My branched network consists of near about 3000 junctions(nodes). I used Darwin designer for the above network with pipe dia varying from 15mm to 5000mm, results show that the Pressure at some nodes was as low as -12000MWC and the highest being 340 MWC. When I imposed pressure restrictions it shows Feasibility issues or no valid data as input. 
 I manually assigned dia to the pipes and results were quite satisfactory (in terms of pressure and velocity, dia being in the range mentioned above). I want to know the reasons for this and what should possibly do for this??

Tom Walski · Accepted Answer

I took a quick look at the file and see several problems. 
 
You only have two design groups which means that all the pipes will either be of one size or another-only two sizes regardless of the flow. You really need to think about what it means for pipes to be in the same design group. They should serve the same population, be in series and carry roughly the same flow 
 
Why are you using Darwin Designer to size all those little branch pipes? They should be at some standard size and using optimization to solve them isn't going to do much for you. 
 
The way you would address this problem is to first not try to optimize all of those little branches. Just focus on a few groups of transmission mains which from one major branching point to the next. 
 
I suggest you read up about genetic algorithms in general for water system design. There are a few hundred papers out there on this topic. You'll realize that the way you are approaching the problem doesn't fit GA's. It's not a problem with Darwin; it is just the nature of GA's. There is a real art to setting up the problem. Most importantly it lies in setting up design groups. 
 
If I was addressing this problem, I would not use Darwin or any GA. Instead I would follow the simple steps I outlines in my previous response.

Wayne Hartell · Answer

I dug into your model today and found some additional problems to those covered in the thread thus far. 
 
It seems like you have competition between constraints. Specifically the maximum velocity constraint and the maximum pressure constraint. In order to meet the velocity constraint, pipe diameters need to be larger, however, this has the effect of increasing downstream pressures which are already by default, hard up against the upper pressure constraint. 
 
By taking the model provided in this thread and making the following changes... 
 
1. Changing the maximum pressure to 300psi* (from 200 psi). 
2. Changing the GA population size to 100**. 
3. Reducing the number of pipe choices 40 to 33 by elimination "odd" sizes below 300mm (10, 30, 50 etc). 
4. Increasing the penalty factor by 10x.*** 
 
This resulted in a feasible run (all constraints met), with a cost of $41,834,204, very first run. (Normally when running GA optimization you would treat it as an iterative process, tweaking the configuration along the way and running numerous runs). 
 
* The 300psi value is not realistic, IMHO, however, take a look at the model and you'll note that the vertical drop from reservoir DC2-sagoda to junction J-3977 is approximately 155m or roughly 220psi. When trying also to keep the head loss in that portion of pipe low (by restricting upper velocity) it does not leave the GA with much choice. It was forced to balance the penalty tradeoff of meeting the upper velocity constraint (choosing a larger pipe to reduce velocity) against meeting the downstream pressure constraint (choosing a smaller pipe in order to increase head loss and reduce downstream pressure). Ultimately the GA was being forced to choose a bad pipe diameter to fulfill those constraints as best it could (the best overall system tradeoff of the downstream effects). (Note: Using a profile from the reservoir to the end of the system and viewing pressure vs elevation is useful to visualize the problem here). 
 
** This is not necessarily required, but something I would normally do when trying to debug an optimization problem such as this. Having a larger population size will help the initial diversity of said population and may improve the likelihood of finding a reasonable result. 
 
*** I found this was necessary to force the GA to weed out velocity constraint violations. I suspect that the costs used in the analysis ($/m) are arbitrary and in that case relatively high. The GA was accepting choosing smaller diameters to save money and absorbing some velocity constraint violations. Multiplying the penalty factor by 10x altered the balance such that the arbitrary costs were no longer less desirable compared to the effect of the constraint violations and all the constraint violations were eliminated (save the altered constraint already mentioned). 
 
In addition to the above, I note that there is still only 1 demand case; so the GA still will be very unlikely to find a more optimal design than that which can be found manually. 
 
Also, as has been mentioned by other responders, it is very much possible to reduce the size of the optimization space (complexity of the problem) by more carefully considering the design groups and also the pipe diameter choices allowable. For example, allowing a 10mm pipe size for the main trunk (and 20mm, 30mm, 40mm etc) is needlessly complicating the optimization problem with choices that never have any realistic chance of being selected. Similarly, considering a 3,300mm diameter pipe at the downstream end of the system is doing the same thing. It is better to create several different pipe cost tables, e.g., "Small pipes", "Medium Pipes" and "Large Pipes" (that may have overlap) and then assign these tables appropriately to the pipes that are being sized, in relation to where they exist in the model. If you want to avoid eliminating pipe sizes that may be of use, leave more sizes initially, do a run, analyze the results, see which pipe sizes are not used or not used very often and use that information to tighten the ranges that the groups cover, or adjust which pipes the groups are assigned to accordingly. 
 
Another thing that was mentioned previously is reducing the number of pipe groups. For example, if there is a run of 3 pipes in the model that in practice would never be constructed a different size, then they should be grouped as such. This will help with the "up/down" size problem, although I think the up/down size problem in this case is also very much a function of the competing constraints. 
 
So to summarize, I believe that the first step to improving the current situation is to rectify the technical issue with constraint violations. If that vertical drop from the reservoir to first junction is accurate then I wonder if some kind of pressure reduction device is necessary? 
 
After resolving the above, I believe the path to success lies in further analyzing the problem set up to reduce the number of pipe choices, with respect to each pipe location for which that choice needs to be made. Definitely it makes no sense to allow a 10mm pipe at the start of the system and also not to allow a 3,300mm pipe at a dead end. If you follow that logic through it should result in perhaps a handful of different pipe cost tables and also hopefully some pipe decisions merged into groups. Doing this things will have a positive effect in two ways: 
 
1. The optimization will perform better (provided the reduction of dimensionality was done judiciously and did not eliminate choices required to meet constraints), 
2. A more constructable design will result due to more contiguous pipe size runs and less different pipe sizes needed overall. 
 
I hope the above information is of some use.

Tom Walski · Answer

I agree with Wayne. If you look at the logic behind Genetic Algorithm optimization, it's really not the best approach. The problem is actually too simple for GA. 
 
All you need to do is run the model with any diameters, determine the flow in each pipe, pick a target design velocity (say 2 m/s), calculate the diameter using 
 
D = sqrt (4Q/pi V) 
 
Round off the diameters to the nearest commercial size. Run the model with those sizes and make minor adjustments to the diameters to get the pressure where you'd want it. 
 
You can export the flows to a spreadsheet and calculate the diameters and do the round off there. Then import the diameters back into WaterGEMS.

Sushma Choure · Answer

Quick Comment- 
 
You shouldn't have separate design group for each pipe, please observe pipes which will have same diameters and assign them into one group. You will get better results. 
 
Also here is technote on Darwin Designer, if you haven't gone through it yet. 
 communities.bentley.com/.../6271.using-darwin-designer

Scott Kampa · Answer

Hello, 
 
I think that part of the issue is that with so many design groups (one for each pipe in the model), that the program is unable to find the solution. Note that the fitness is a very large value. The pipes are changing sizes, which you can see if you export the new pipe sizes out to a new physical alternative. The problem is that the program stops looking for new solutions because a better wasn't found. GA really only compares with what it has already been tested. 
 
I would recommend setting up the design groups in a more logical fashion. Some details will be found in the link that Sushma provided in her recent link. Grouping similar pipes or pipes that you expect to have the same diameter will allow the program to test more possible solutions and likely find a better one that matches better with the expected results. 
 
The link also has some possible troubleshooting steps that you can try. In addition, there are a few Quick Start Lessons available in the Help pulldown menu, which could offer further guidance on using Darwin Designer. 
 
Regards, 
Scott