Valves (including PRV and FCV) treated as open pipes!!!

[AfricAnand]

I have a model (too large include in mail) with 200 valves(fcv and prv). Epanet v2.0 solves the hydraulic model with valves operating as expected with non-reversible flow controls. Surprisingly, running the model with the Epanet3 library resorts to valves behaving as open pipes/links with reversible flows!!

Is this a feature in the new Epanet 3 library?

[LRossman]

EPANET-dev is still a work in progress, so it may not provide reliable results for all networks just yet. It isn't supposed to change the way that PRVs behave from that of EPANET 2. Perhaps @AfricAnand could post your network to a file sharing service (like Box or Google Drive) so that it could be used for future testing of the new code as it undergoes further development.

[silasvorne]

@LRossman The new problem is still focused on the valve(TCV this time). Epanet-dev results in a wide range of negative pressure on a model with 6000+ TCVs. However, there is no negative pressure in Epanet2. Should I trust Epanet2 if they lead to different results ?

[LRossman]

@wqyuyu please see my earlier comment regarding the current status of EPANET-dev. One feature it does have is that it reports the largest error in satisfying the head loss equation for all links as well as the largest flow continuity error for all nodes. That way you can tell how well a given solution satisfies the governing hydraulic conservation of mass and energy equations. EPANET 2 does not report this.

[silasvorne]

@LRossman Thanks a lot. There are four limits in source code.
bool GGASolver::hasConverged() { return ( hydBalance.maxHeadErr < headErrLimit ) && ( hydBalance.maxFlowErr < flowErrLimit ) && ( hydBalance.maxFlowChange < flowChangeLimit ) && ( hydBalance.totalFlowChange < flowRatioLimit ); }
It indicates the errors as you mentioned. According to the strict limits, maybe I should trust Epanet-dev and check the results with Epanet2. However，I can't help but doubt the uniqueness of the solution.

[silasvorne]

@LRossman I have found the reason. In Epanet-dev, there is a default minor loss coefficient which does not exist in Epanet2.