Flow, Connectivity, and System Vulnerability: How Linear Algebra Reveals Bottlenecks, Resilience, and Failure Risk

Last Updated July 3, 2026

Flow, connectivity, and system vulnerability explain how connected systems remain functional, become constrained, or fail under disruption. A network is not vulnerable simply because it has many connections or few connections. Vulnerability depends on how flow moves, which nodes and edges connect critical regions, where bottlenecks occur, how much redundancy exists, what fails together, and how disruption propagates through the structure.

This article closes Part V of the Linear Algebra for Systems Modeling by connecting graph connectivity, flow networks, incidence structure, cuts, bottlenecks, redundancy, robustness, resilience, cascading failure, criticality, interdependence, sparse computation, scenario analysis, sensitivity testing, and responsible interpretation.

The central modeling question is not only “Is the system connected?” It is “What kind of connectivity matters, what flows through it, where can the system be separated, which disruptions reduce service, and how should vulnerability be interpreted before mathematical outputs guide action?”

Connectivity is one of the most basic ideas in graph theory, but in systems modeling it becomes much richer than the question of whether paths exist. A system can be connected but fragile, disconnected but locally resilient, highly centralized but efficient, redundant but expensive, sparse but robust, or dense but vulnerable to correlated failures. Whether connectivity helps or harms depends on the flows, constraints, dependencies, and hazards being modeled.

Linear algebra provides tools for representing this structure. Adjacency matrices encode direct connections. Incidence matrices encode node-edge relationships. Laplacians encode connectivity and diffusion. Flow vectors encode movement. Capacity vectors encode limits. Cut structures reveal separating boundaries. Eigenvalues can summarize connectivity and fragmentation. Scenario matrices can represent disruptions, recoveries, and state changes. These tools are powerful, but they must be tied to the system question: vulnerability to what, for whom, under what assumptions, and over what time horizon?

Why Connectivity and Vulnerability Matter

Connectivity matters because it determines whether movement, communication, influence, service, energy, water, goods, information, or risk can travel through a system. Vulnerability matters because connected systems can fail in ways that are not obvious from isolated asset inspection. A small bridge closure may isolate a region. A power substation failure may disrupt water, communication, and health services. A supply-chain bottleneck may affect multiple downstream sectors. A communication hub may be structurally central even if it is physically small.

System vulnerability is a relationship among structure, flow, exposure, demand, capacity, redundancy, interdependence, and consequence. It is not one number.

Connectivity analysis becomes vulnerability analysis when it is linked to disruption and consequence.

Back to top ↑

Connectivity as a Systems Property

Connectivity describes whether nodes are connected through paths. In an undirected graph, two nodes are connected if some path links them. In a directed graph, reachability depends on direction. In a weighted or capacitated graph, connection may exist but be weak, costly, slow, unreliable, or insufficient for demand.

In systems modeling, connectivity should always be interpreted through the meaning of the edge. A road edge supports movement. A citation edge supports reference. A dependency edge supports reliance. A communication edge supports signal exchange. A supply-chain edge supports transfer. Different edges imply different kinds of vulnerability.

A network can appear connected mathematically while being functionally disconnected under capacity, time, institutional, or hazard constraints.

Back to top ↑

Paths, Reachability, and Components

Paths and components are the foundation of connectivity analysis. A component is a maximal set of nodes connected to each other. In directed graphs, strongly connected components require mutual reachability, while weakly connected components ignore edge direction.

Component analysis is often the first step after disruption. Removing nodes or edges can split a network into isolated regions, revealing access vulnerability and service fragmentation.

Back to top ↑

Edge Connectivity and Node Connectivity

Edge connectivity asks how many edges must be removed to disconnect a graph. Node connectivity asks how many nodes must be removed to disconnect a graph. These measures describe structural robustness, but their interpretation depends on whether the removed elements are realistic failure points.

A bridge or articulation point can be technically small but systemically important. In infrastructure, supply chains, communication systems, or public services, these elements often deserve scenario testing.

Back to top ↑

Flow Connectivity

Flow connectivity asks whether the network can support required movement under capacities and balance constraints. A path may exist, but if its capacity is too low, it may not provide adequate service.

Flow connectivity is central for transportation, water, energy, logistics, communication, public health, and emergency response systems. The system is not merely connected or disconnected; it may be partially functional, overloaded, congested, or service-deficient.

Flow vulnerability is therefore about service adequacy, not only graph connectivity.

Back to top ↑

Cuts, Separators, and Bottlenecks

A cut separates a network into parts. In flow models, the capacity of a cut can limit throughput from source to sink. In connectivity models, a separator can fragment access, communication, or dependency structure.

Bottlenecks emerge when a small set of nodes or edges carries disproportionate responsibility for system connectivity or flow. They are especially important when alternative paths do not exist or have insufficient capacity.

Cut analysis helps connect graph structure to vulnerability: where does the system become separated, and what consequences follow?

Back to top ↑

Redundancy and Alternative Paths

Redundancy means the system has alternatives: multiple paths, spare capacity, backup systems, substitute suppliers, alternative routes, reserve capacity, or decentralized service options. But redundancy must be usable under the scenario being modeled.

Redundancy can reduce vulnerability, but it can also increase complexity, cost, and exposure. Network models should test whether redundancy actually preserves service under disruption.

Back to top ↑

Centralization and Fragility

Centralized networks can be efficient because flows concentrate through important hubs. But centralization can create fragility when a small number of nodes or edges become essential to system performance.

Centrality metrics can help identify concentration, but centrality must be interpreted alongside capacity, demand, failure probability, recovery difficulty, and consequences for affected users.

Back to top ↑

Cascading Failure and Interdependence

Cascading failure occurs when disruption spreads through a network or across network layers. One component fails, load shifts, dependencies break, capacities degrade, and additional components fail. Interdependence makes cascading failure more difficult because systems rely on each other.

Cascade models require explicit propagation rules. Connectivity alone does not determine failure; thresholds, loads, dependencies, time delays, controls, and recovery actions matter.

Back to top ↑

Vulnerability Metrics

System vulnerability can be measured in many ways: loss of connectivity, loss of flow, unmet demand, increase in travel time, service shortfall, component criticality, fragmentation, affected population, recovery delay, or economic loss. The chosen metric determines what the model sees.

A vulnerability metric is not neutral. It encodes what counts as harm, what counts as service, and whose experience is measured.

Back to top ↑

Resilience, Robustness, and Recovery

Robustness describes how well a system maintains performance under disruption. Resilience describes how a system absorbs, adapts, recovers, or transforms after disruption. Recovery describes the restoration path over time.

Resilience analysis should not only ask how quickly the system returns to normal. Sometimes normal was already fragile, inequitable, or unsustainable.

Back to top ↑

Spectral Connectivity and Laplacians

Graph Laplacians provide a matrix-based view of connectivity. For an undirected graph, the combinatorial Laplacian is:

The second-smallest eigenvalue of the Laplacian, often called algebraic connectivity, provides one measure of how strongly connected a graph is. Larger values generally indicate stronger connectedness, while values near zero indicate weak connection or near-separation.

Spectral metrics are useful summaries, but they should not replace domain-specific flow, demand, and consequence analysis.

Back to top ↑

Scenario Analysis and Stress Testing

Vulnerability analysis requires scenarios. A scenario specifies what fails, what changes, what demand occurs, what capacities are reduced, what dependencies are activated, and how recovery proceeds. Without scenarios, vulnerability metrics can become abstract structural scores.

Stress testing should include plausible failures, severe failures, and compound events. It should also distinguish technical performance from social consequence.

Back to top ↑

Sensitivity and Uncertainty

Vulnerability conclusions can be sensitive to uncertain data and modeling choices. Edge capacities may be outdated. Demand may be estimated. Dependencies may be incomplete. Failure probabilities may be uncertain. Recovery assumptions may be optimistic. Boundaries may exclude upstream or downstream systems.

Reliable vulnerability modeling depends less on one precise score and more on whether conclusions hold across reasonable assumptions.

Back to top ↑

System Vulnerability Workflow

A reproducible workflow for flow, connectivity, and vulnerability should preserve graph construction, matrix representation, flow assumptions, disruption scenarios, metric definitions, sensitivity tests, and interpretation warnings.

This workflow keeps mathematical analysis connected to systems meaning and responsible use.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Flow, connectivity, and system vulnerability connect graph theory, adjacency matrices, incidence matrices, Laplacians, cuts, flows, capacities, connected components, edge connectivity, node connectivity, spectral connectivity, scenario perturbations, sparse computation, and resilience metrics.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for flow, connectivity, and vulnerability should document node tables, edge tables, graph boundaries, edge meanings, capacities, demands, baseline metrics, disruption scenarios, removed nodes or edges, degraded capacities, component changes, reachability losses, flow losses, cut structures, recovery assumptions, sensitivity tests, and interpretation warnings.

The companion repository treats vulnerability analysis as an auditable network-modeling workflow. Python, R, Julia, SQL, Haskell, C, C++, Fortran, Rust, Go, notebooks, schemas, generated outputs, Canvas artifacts, advanced reports, and calculators each support a different layer of reproducible connectivity and vulnerability analysis.

For this article, the computational examples focus on baseline connectivity, bridge identification, disruption testing, component changes, capacity-loss summaries, service-impact diagnostics, and governance records for vulnerability interpretation.

Back to top ↑

Python Workflow: Vulnerability Audit

The Python workflow below builds a small infrastructure-style network, computes baseline connectivity, removes a critical edge, compares disrupted components, estimates lost capacity, and writes auditable outputs.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json


@dataclass(frozen=True)
class EdgeRecord:
    source: str
    target: str
    capacity: float
    edge_type: str


@dataclass(frozen=True)
class VulnerabilityAudit:
    network_name: str
    node_count: int
    edge_count: int
    disrupted_edge: str
    baseline_component_count: int
    disrupted_component_count: int
    baseline_reachable_pairs: int
    disrupted_reachable_pairs: int
    reachable_pair_loss: int
    disrupted_capacity_loss: float
    largest_component_size_after_disruption: int
    governance_warning: str


def build_network() -> tuple[list[str], list[EdgeRecord]]:
    nodes = [
        "source_region",
        "bridge_corridor",
        "north_hub",
        "south_hub",
        "hospital",
        "warehouse",
        "service_region",
    ]

    edges = [
        EdgeRecord("source_region", "bridge_corridor", 20.0, "access"),
        EdgeRecord("bridge_corridor", "north_hub", 18.0, "access"),
        EdgeRecord("bridge_corridor", "south_hub", 12.0, "access"),
        EdgeRecord("north_hub", "hospital", 10.0, "service"),
        EdgeRecord("south_hub", "warehouse", 8.0, "logistics"),
        EdgeRecord("warehouse", "hospital", 6.0, "supply"),
        EdgeRecord("hospital", "service_region", 9.0, "service"),
        EdgeRecord("south_hub", "service_region", 7.0, "access"),
    ]

    return nodes, edges


def adjacency(nodes: list[str], edges: list[EdgeRecord]) -> dict[str, set[str]]:
    adj = {node: set() for node in nodes}
    for edge in edges:
        adj[edge.source].add(edge.target)
        adj[edge.target].add(edge.source)
    return adj


def components(nodes: list[str], edges: list[EdgeRecord]) -> list[set[str]]:
    adj = adjacency(nodes, edges)
    seen: set[str] = set()
    comps: list[set[str]] = []

    for node in nodes:
        if node in seen:
            continue
        stack = [node]
        comp: set[str] = set()
        seen.add(node)
        while stack:
            current = stack.pop()
            comp.add(current)
            for neighbor in adj[current]:
                if neighbor not in seen:
                    seen.add(neighbor)
                    stack.append(neighbor)
        comps.append(comp)

    return comps


def reachable_pairs(nodes: list[str], edges: list[EdgeRecord]) -> int:
    comps = components(nodes, edges)
    return sum(len(comp) * (len(comp) - 1) // 2 for comp in comps)


def remove_edge(edges: list[EdgeRecord], source: str, target: str) -> list[EdgeRecord]:
    return [
        edge for edge in edges
        if not (
            {edge.source, edge.target} == {source, target}
        )
    ]


def build_audit() -> tuple[VulnerabilityAudit, list[str], list[EdgeRecord], list[EdgeRecord]]:
    nodes, edges = build_network()
    disrupted_source = "source_region"
    disrupted_target = "bridge_corridor"
    disrupted_edges = remove_edge(edges, disrupted_source, disrupted_target)

    baseline_components = components(nodes, edges)
    disrupted_components = components(nodes, disrupted_edges)

    baseline_pairs = reachable_pairs(nodes, edges)
    disrupted_pairs = reachable_pairs(nodes, disrupted_edges)

    lost_edge = next(
        edge for edge in edges
        if {edge.source, edge.target} == {disrupted_source, disrupted_target}
    )

    audit = VulnerabilityAudit(
        network_name="synthetic_flow_connectivity_vulnerability_network",
        node_count=len(nodes),
        edge_count=len(edges),
        disrupted_edge=f"{disrupted_source}--{disrupted_target}",
        baseline_component_count=len(baseline_components),
        disrupted_component_count=len(disrupted_components),
        baseline_reachable_pairs=baseline_pairs,
        disrupted_reachable_pairs=disrupted_pairs,
        reachable_pair_loss=baseline_pairs - disrupted_pairs,
        disrupted_capacity_loss=lost_edge.capacity,
        largest_component_size_after_disruption=max(len(comp) for comp in disrupted_components),
        governance_warning=(
            "Vulnerability metrics depend on node definitions, edge meanings, graph boundary, "
            "capacity semantics, disruption scenario, performance metric, demand assumptions, "
            "dependency rules, recovery assumptions, and affected-population interpretation."
        ),
    )

    return audit, nodes, edges, disrupted_edges


def write_outputs(output_dir: Path) -> None:
    (output_dir / "tables").mkdir(parents=True, exist_ok=True)
    (output_dir / "json").mkdir(parents=True, exist_ok=True)

    audit, nodes, edges, disrupted_edges = build_audit()
    audit_row = asdict(audit)

    with (output_dir / "tables" / "vulnerability_audit.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(audit_row.keys()))
        writer.writeheader()
        writer.writerow(audit_row)

    with (output_dir / "tables" / "baseline_edges.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(asdict(edges[0]).keys()))
        writer.writeheader()
        writer.writerows(asdict(edge) for edge in edges)

    with (output_dir / "tables" / "disrupted_edges.csv").open(
        "w", newline="", encoding="utf-8"
    ) as handle:
        writer = csv.DictWriter(handle, fieldnames=list(asdict(edges[0]).keys()))
        writer.writeheader()
        writer.writerows(asdict(edge) for edge in disrupted_edges)

    (output_dir / "json" / "vulnerability_audit.json").write_text(
        json.dumps(audit_row, indent=2, sort_keys=True),
        encoding="utf-8",
    )


if __name__ == "__main__":
    write_outputs(Path("outputs"))
    print("Flow, connectivity, and vulnerability audit complete.")

This workflow keeps the disruption scenario, component change, reachable-pair loss, capacity loss, and governance warning together.

Back to top ↑

R Workflow: Connectivity Diagnostics

R can support vulnerability diagnostics by comparing baseline and disrupted edge lists, estimating component fragmentation, and exporting scenario records.

nodes <- c(
  "source_region",
  "bridge_corridor",
  "north_hub",
  "south_hub",
  "hospital",
  "warehouse",
  "service_region"
)

edges <- data.frame(
  source = c("source_region", "bridge_corridor", "bridge_corridor", "north_hub", "south_hub", "warehouse", "hospital", "south_hub"),
  target = c("bridge_corridor", "north_hub", "south_hub", "hospital", "warehouse", "hospital", "service_region", "service_region"),
  capacity = c(20, 18, 12, 10, 8, 6, 9, 7),
  edge_type = c("access", "access", "access", "service", "logistics", "supply", "service", "access")
)

disrupted_source <- "source_region"
disrupted_target <- "bridge_corridor"

disrupted_edges <- edges[
  !(edges$source == disrupted_source & edges$target == disrupted_target) &
  !(edges$source == disrupted_target & edges$target == disrupted_source),
]

# This compact diagnostic records the scenario and uses known component counts
# for the synthetic teaching graph. Larger workflows can replace this with igraph.
baseline_component_count <- 1
disrupted_component_count <- 2
baseline_reachable_pairs <- choose(length(nodes), 2)
disrupted_reachable_pairs <- choose(1, 2) + choose(6, 2)

lost_capacity <- edges$capacity[
  edges$source == disrupted_source & edges$target == disrupted_target
]

audit_record <- data.frame(
  network_name = "synthetic_flow_connectivity_vulnerability_network",
  node_count = length(nodes),
  edge_count = nrow(edges),
  disrupted_edge = paste(disrupted_source, disrupted_target, sep = "--"),
  baseline_component_count = baseline_component_count,
  disrupted_component_count = disrupted_component_count,
  baseline_reachable_pairs = baseline_reachable_pairs,
  disrupted_reachable_pairs = disrupted_reachable_pairs,
  reachable_pair_loss = baseline_reachable_pairs - disrupted_reachable_pairs,
  disrupted_capacity_loss = lost_capacity,
  largest_component_size_after_disruption = 6,
  governance_warning = paste(
    "Vulnerability metrics depend on node definitions, edge meanings, graph boundary,",
    "capacity semantics, disruption scenario, performance metric, demand assumptions,",
    "dependency rules, recovery assumptions, and affected-population interpretation."
  )
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)

write.csv(audit_record, "outputs/tables/r_vulnerability_audit.csv", row.names = FALSE)
write.csv(edges, "outputs/tables/r_baseline_edges.csv", row.names = FALSE)
write.csv(disrupted_edges, "outputs/tables/r_disrupted_edges.csv", row.names = FALSE)

print(audit_record)

This R workflow keeps disruption logic and vulnerability interpretation visible even in a compact teaching example.

Back to top ↑

Haskell Workflow: Typed Vulnerability Records

Haskell can represent vulnerability audit output as typed records, keeping the scenario, metric, and interpretation warning attached to the output.

module Main where

data VulnerabilityAudit = VulnerabilityAudit
  { networkName :: String
  , nodeCount :: Int
  , edgeCount :: Int
  , disruptedEdge :: String
  , baselineComponentCount :: Int
  , disruptedComponentCount :: Int
  , baselineReachablePairs :: Int
  , disruptedReachablePairs :: Int
  , reachablePairLoss :: Int
  , disruptedCapacityLoss :: Double
  , largestComponentSizeAfterDisruption :: Int
  , governanceWarning :: String
  } deriving (Show)

buildAudit :: VulnerabilityAudit
buildAudit =
  VulnerabilityAudit
    "synthetic_flow_connectivity_vulnerability_network"
    7
    8
    "source_region--bridge_corridor"
    1
    2
    21
    15
    6
    20.0
    6
    "Vulnerability metrics depend on node definitions, edge meanings, graph boundary, capacity semantics, disruption scenario, performance metric, demand assumptions, dependency rules, recovery assumptions, and affected-population interpretation."

main :: IO ()
main =
  print buildAudit

The typed record helps prevent vulnerability scores from being separated from the scenario that produced them.

Back to top ↑

SQL Workflow: Vulnerability Registry

SQL can document flow, connectivity, and vulnerability assumptions when models support infrastructure planning, resilience dashboards, supply-chain risk review, emergency management, service access analysis, or governance reporting.

CREATE TABLE vulnerability_modeling_registry (
    assumption_key TEXT PRIMARY KEY,
    assumption_name TEXT NOT NULL,
    mathematical_role TEXT NOT NULL,
    systems_modeling_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'node_definition',
  'Node definition',
  'Defines graph vertices.',
  'Determines which assets, communities, facilities, regions, or service points can be affected.',
  'Changing nodes changes connectivity and vulnerability metrics.'
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'edge_meaning',
  'Edge meaning',
  'Defines graph relationships.',
  'Determines whether links represent access, flow, dependence, communication, service, or exposure.',
  'Different edge meanings should not be mixed without documentation.'
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'capacity_semantics',
  'Capacity semantics',
  'Defines limits on edge or node flow.',
  'Determines whether vulnerability reflects throughput, access, service, demand, or overload.',
  'Capacity requires units, time scale, and provenance.'
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'disruption_scenario',
  'Disruption scenario',
  'Defines removed nodes, removed edges, degraded capacities, or dependency failures.',
  'Determines which stress condition is being tested.',
  'Different scenarios reveal different vulnerabilities.'
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'performance_metric',
  'Performance metric',
  'Defines what loss is measured.',
  'Determines whether output means fragmentation, flow loss, demand shortfall, delay, or recovery time.',
  'Metric choice encodes what the model treats as harm.'
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'dependency_rule',
  'Dependency rule',
  'Defines propagation across connected systems or layers.',
  'Supports cascading-failure and interdependence analysis.',
  'Propagation rules must be justified and sensitivity-tested.'
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'recovery_assumption',
  'Recovery assumption',
  'Defines restoration timing, sequence, resources, and constraints.',
  'Determines resilience over time.',
  'Recovery models can be overly optimistic without access, labor, safety, and supply constraints.'
);

INSERT INTO vulnerability_modeling_registry VALUES
(
  'affected_population',
  'Affected population',
  'Connects network loss to people, communities, services, or institutions.',
  'Supports equity, access, public need, and accountability analysis.',
  'Technical vulnerability does not automatically equal social consequence.'
);

SELECT
    assumption_name,
    mathematical_role,
    systems_modeling_role,
    review_warning
FROM vulnerability_modeling_registry
ORDER BY assumption_key;

This registry keeps vulnerability modeling tied to node definitions, edge meanings, capacities, scenarios, performance metrics, dependency rules, recovery assumptions, and affected populations.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports vulnerability audits, baseline and disrupted edge lists, connectivity diagnostics, component analysis, reachability-loss summaries, capacity-loss summaries, SQL governance tables, generated outputs, advanced mathematical audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Flow, connectivity, and vulnerability models are powerful because they reveal how connected systems can sustain service, fragment, overload, or fail. They can identify bottlenecks, critical assets, weak cuts, isolated regions, overloaded pathways, fragile dependencies, and recovery priorities. Their limits arise because vulnerability is not purely structural. It depends on hazards, demand, capacity, operating conditions, institutional constraints, recovery resources, affected populations, and values.

A disconnected component is not automatically the greatest social harm. A high-centrality node is not automatically the highest public priority. A minimum cut is not automatically the best investment target. A resilient network in a graph may still be fragile under capacity limits, staffing constraints, cyber dependencies, spatial exposure, or unequal access. A technical recovery path may not be feasible under labor, safety, supply, jurisdictional, or community constraints.

Responsible use requires documenting the graph boundary, node definitions, edge meanings, capacity assumptions, demand assumptions, disruption scenarios, performance metrics, dependency rules, recovery assumptions, uncertainty, data provenance, and affected populations. Vulnerability models should make risk and tradeoffs visible, not convert complex systems into unquestioned technical rankings.

Back to top ↑

Related Articles

• What Is Linear Algebra for Systems Modeling?
• Network Adjacency Matrices
• Incidence Structure and Graph Representation
• Graph Theory Foundations for Systems Modeling
• PageRank and Network Influence Models
• Network Flow Modeling
• Infrastructure Network Models
• Control Systems Modeling
• Linear Dynamical Systems
• Matrix Differential Equations
• Markov Chains and Transition Matrices
• Long-Run Behavior in State Transition Systems
• Stability Analysis with Eigenvalues
• Orthogonal Decomposition and Structured Approximation
• Singular Value Decomposition
• Linear Algebra for Systems Modeling
• Mathematical Modeling
• Systems Modeling
• Algorithms & Computational Reasoning
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Ahuja, R.K., Magnanti, T.L. and Orlin, J.B. (1993) Network Flows: Theory, Algorithms, and Applications. Upper Saddle River, NJ: Prentice Hall. Available at: https://mitmgmtfaculty.mit.edu/jorlin/network-flows/.
• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Buldyrev, S.V., Parshani, R., Paul, G., Stanley, H.E. and Havlin, S. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Ford, L.R. and Fulkerson, D.R. (1962) Flows in Networks. Princeton, NJ: Princeton University Press. Available at: https://press.princeton.edu/books/hardcover/9780691625393/flows-in-networks.
• Johansson, J. and Hassel, H. (2010) ‘An approach for modelling interdependent infrastructures in the context of vulnerability analysis’, Reliability Engineering & System Safety, 95(12), pp. 1335–1344. Available at: https://doi.org/10.1016/j.ress.2010.06.010.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• Ouyang, M. (2014) ‘Review on modeling and simulation of interdependent critical infrastructure systems’, Reliability Engineering & System Safety, 121, pp. 43–60. Available at: https://doi.org/10.1016/j.ress.2013.06.040.
• Rinaldi, S.M., Peerenboom, J.P. and Kelly, T.K. (2001) ‘Identifying, understanding, and analyzing critical infrastructure interdependencies’, IEEE Control Systems Magazine, 21(6), pp. 11–25. Available at: https://doi.org/10.1109/37.969131.
• Schrijver, A. (2003) Combinatorial Optimization: Polyhedra and Efficiency. Berlin: Springer. Available at: https://link.springer.com/book/10.1007/978-3-540-44389-6.
• U.S. Cybersecurity and Infrastructure Security Agency (n.d.) Critical Infrastructure Sectors. Available at: https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/critical-infrastructure-sectors.

Back to top ↑

References

• Ahuja, R.K., Magnanti, T.L. and Orlin, J.B. (1993) Network Flows: Theory, Algorithms, and Applications. Upper Saddle River, NJ: Prentice Hall. Available at: https://mitmgmtfaculty.mit.edu/jorlin/network-flows/.
• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Buldyrev, S.V., Parshani, R., Paul, G., Stanley, H.E. and Havlin, S. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Ford, L.R. and Fulkerson, D.R. (1962) Flows in Networks. Princeton, NJ: Princeton University Press. Available at: https://press.princeton.edu/books/hardcover/9780691625393/flows-in-networks.
• Johansson, J. and Hassel, H. (2010) ‘An approach for modelling interdependent infrastructures in the context of vulnerability analysis’, Reliability Engineering & System Safety, 95(12), pp. 1335–1344. Available at: https://doi.org/10.1016/j.ress.2010.06.010.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• Ouyang, M. (2014) ‘Review on modeling and simulation of interdependent critical infrastructure systems’, Reliability Engineering & System Safety, 121, pp. 43–60. Available at: https://doi.org/10.1016/j.ress.2013.06.040.
• Rinaldi, S.M., Peerenboom, J.P. and Kelly, T.K. (2001) ‘Identifying, understanding, and analyzing critical infrastructure interdependencies’, IEEE Control Systems Magazine, 21(6), pp. 11–25. Available at: https://doi.org/10.1109/37.969131.
• Schrijver, A. (2003) Combinatorial Optimization: Polyhedra and Efficiency. Berlin: Springer. Available at: https://link.springer.com/book/10.1007/978-3-540-44389-6.
• U.S. Cybersecurity and Infrastructure Security Agency (n.d.) Critical Infrastructure Sectors. Available at: https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/critical-infrastructure-sectors.

Back to top ↑