Networks (experimental)
Overview
What the Networks feature does, how it differs from single-route mode, and the two design engines.
The Networks feature designs a whole CO₂ pipeline network connecting many capture sources to many storage sinks — an N:M problem. This is distinct from the single-route tool, which optimises one source-to-sink corridor at a time.
Experimental feature. Networks mode is under active development. Some technical aspects are still being validated with domain researchers. If you find results that don’t make sense, please open a GitHub issue or email co2gis.support@gmail.com.
Why a network beats N independent routes
Running a separate pipeline from each emitter to its nearest sink is wasteful: nearby flows should share a trunk. Pipe cost grows roughly with diameter, but carrying capacity grows much faster (Darcy–Weisbach: capacity ). So one larger pipe carrying two combined flows is cheaper than two smaller parallel pipes carrying them separately.
The Networks feature finds where flows should merge into trunks and sizes everything accordingly. Two types of pipe emerge from this:
- Spurs — feeder pipes from a source toward the network.
- Trunks — shared, higher-flow segments where two or more spurs have merged. A trunk carries the sum of the flows that fed into it.
How it is gated
Network mode is off by default. Enable it in the plugin Settings dialog, then reload the plugin. This reveals a Single / Network mode selector inside the LCP tab and, once a network is created, a Network mode in the Price Estimation tab.
Network mode reuses the same combined COMET cost raster as single-route mode. Everything you already did to build the cost surface — land use, slope, corridors, crossings — feeds the network design unchanged.
The two engines
| Heuristic (fast) | MILP (optimal) | |
|---|---|---|
| Extra dependencies | none | pulp + highspy |
| Extra inputs | none | capture target, candidate-graph density |
| Connects which sources | every source | an optimally chosen subset meeting a capture target |
| How trunks form | implicitly, where cell paths overlap | explicitly, via flow conservation at junctions |
| Pipe sizing | one diameter per pipe, from its own flow | a discrete standard size chosen by the solver |
| Optimality | a good greedy tree | provably minimum cost (within the candidate graph) |
| Speed | one r.cost per source | one r.cost per candidate node + MIP solve time |
Both engines produce the same output format (network.gpkg) so downstream pricing is identical. See The two engines for a deeper explanation.
The end-to-end pipeline
Both engines share the same five-phase shape:
COMET raster → r.cost → [Heuristic tree | MILP] → r.drain → network.gpkg → Network CAPEX
- COMET cost surface — the combined raster built by the earlier tabs.
r.cost— GRASS least-cost accumulation from each source (heuristic) or each candidate node (MILP).- Engine — greedy tree growth, or the fixed-charge MILP solve.
r.drain— trace the selected links back into real pipeline geometry.- Network CAPEX — each segment sized for its own flow, with spacing and junction boosters.
Next: Using the feature.