Check valves and reverse flow

A non-return valve has one job: pass flow one way and block it the other. A model that treats it as a plain fitting gets the forward case right and the reverse case badly wrong, letting flow run backwards through a valve that would physically slam shut. Fluid Network Studio models check valves that actually block reverse flow, and cross-checks the behaviour against OWA-EPANET 2.2.

It runs in a browser tab, with no desktop licence and no install. Check valves are part of the incompressible-liquid solve, available from the free Explorer tier.

A check valve that shuts, not just resists

A check-valve node behaves in two states. With flow in the allowed direction it is a plain minor loss, identical to a fitting of the same K. Against the allowed direction it shuts, and its through-flow is exactly zero. The valve picks its state as part of the solve, so a network with several non-return valves settles to a consistent set of open and shut valves rather than being fixed by hand.

This matters because the wrong model is not a small error. On the network shown on the verification page, a loss-only fitting would pass 282 L/s backwards; the check valve carries exactly zero. That is the size of the mistake a real non-return valve exists to prevent, and it is the defect this element closes.

Cross-checked against EPANET

The forward and reverse behaviour is verified. On the verification page a check valve passes forward flow bit-identically to a plain fitting of the same K, and shuts to exactly zero flow on a reverse gradient. The case is solved live by the same solver the app runs and agrees with OWA-EPANET 2.2, the reference implementation, in the same global-gradient family. The non-return logic is solved as an outer loop around the verified steady solver, so a network with no check valve solves exactly as it did before.

Import an EPANET model with its check valves intact

An EPANET .inp model with non-return valves imports with that behaviour preserved: a check valve comes across as a check valve, not as a fixed loss that would let flow run backwards. An existing model keeps protecting against reverse flow the way it was built to.

What it does and does not do

Fluid Network Studio models the steady-state non-return behaviour of a check valve and cross-checks it against EPANET. It does not model the dynamics of valve closure: the pressure surge of a slamming check valve on a pump trip is a water-hammer study and belongs in a dedicated surge package. It supports your engineering work rather than replacing it; results should be reviewed by a qualified engineer for the specific application.

Frequently asked questions

Does the check valve actually block reverse flow?

Yes. In the allowed direction it is a plain minor loss; against it, the valve shuts and its through-flow is exactly zero. Earlier check-valve fittings only added a loss and would let flow run backwards, which this element fixes.

Is the behaviour verified?

Yes. The verification page shows a check valve passing forward flow as a plain fitting and shutting to exactly zero in reverse, solved live and cross-checked against OWA-EPANET 2.2, the reference implementation.

Does it import check valves from an EPANET .inp file?

Yes. A non-return valve in an imported .inp comes across as a check valve, preserving its reverse-flow protection rather than importing as a fixed loss.

Does it model check-valve slam and surge?

No. It models the steady-state non-return behaviour. The pressure transient of a check valve slamming shut on a pump trip is a water-hammer study, which is out of scope and belongs in a surge package.

Model your check valves

Draw the network, place your non-return valves, and see which sit open and which shut at the operating point. Open the Studio, lay out your pipes and check valves, and read the state and flow of each one.

Open the Studio and model your check valves in your browser. Non-return valves are part of the incompressible-liquid solve, from the free Explorer tier.