Case Study: Network System Modeling: How Linear Algebra Represents Connection, Flow, and Vulnerability

Last Updated July 6, 2026

Network System Modeling shows how linear algebra turns connected systems into matrices, diagnostics, simulations, and responsible interpretation. Networks appear in infrastructure, transportation, energy grids, supply chains, communication systems, ecological systems, public health, knowledge retrieval, institutional coordination, and economic interdependence. Linear algebra provides the core language for representing these connections as adjacency matrices, incidence matrices, Laplacians, flow matrices, transition matrices, and state vectors.

This article opens Part X of the Linear Algebra for Systems Modeling series by applying earlier concepts to a complete network case study: nodes, edges, weights, direction, adjacency, incidence, degree, paths, connectivity, centrality, flow, vulnerability, spectral structure, transition dynamics, robustness, residual checks, sensitivity analysis, visualization, reproducible computation, and responsible interpretation.

The central modeling question is not only “Can this system be represented as a network?” It is “What kind of network representation best matches the system, what does the matrix reveal, and where can network simplification distort reality?”

A network model begins with a simple abstraction: entities become nodes, relationships become edges, and the structure becomes a matrix. But this simplicity hides important choices. A road segment, power substation, hospital, server, species, firm, document, institution, or person can become a node depending on the modeling purpose. An edge can mean distance, capacity, probability, dependency, communication, similarity, citation, ownership, transfer, or influence.

Linear algebra makes the network computable. An adjacency matrix records connections. An incidence matrix records edge-node relationships. A graph Laplacian supports connectivity and diffusion analysis. A transition matrix supports movement across states. A flow matrix supports capacity and load. Eigenvectors and singular vectors reveal structural modes. But every computation inherits the meaning and limitations of the representation.

Why Network System Modeling Matters

Network system modeling matters because many systems are defined less by isolated parts than by relationships among parts. A transportation network depends on routes and transfer points. A power grid depends on generation, transmission, substations, and load. A supply chain depends on firms, goods, contracts, delays, and substitutions. A knowledge system depends on documents, citations, concepts, embeddings, and retrieval paths.

Linear algebra helps make these relationships analyzable. It allows network structure to be stored, transformed, decomposed, normalized, simulated, visualized, and audited. The same matrix can support questions about connectivity, flow, vulnerability, influence, clustering, redundancy, transition, and control.

A network model is useful when relationship structure matters. It is risky when the network abstraction hides time, behavior, geography, capacity, institutions, or causality.

Back to top ↑

Case Study Framing

This case study uses a small synthetic infrastructure-service network. The system contains five service nodes connected by weighted links. Each link has a capacity-like weight. The goal is not to create a realistic infrastructure map, but to demonstrate how a responsible network modeling workflow moves from representation to diagnostics to interpretation.

The case asks:

• Which nodes are highly connected?
• Which links carry important structural dependence?
• How does the network change if one edge or node is removed?
• Which matrix representation best fits the modeling purpose?
• What should and should not be inferred from the computed metrics?

The value of the case study is not the synthetic numbers. It is the workflow discipline: define representation, compute diagnostics, test sensitivity, document limits, and communicate responsibly.

Back to top ↑

Nodes, Edges, and System Boundaries

Every network model begins with boundary choices. What counts as a node? What counts as an edge? Are edges directed or undirected? Are weights capacities, probabilities, costs, distances, risks, similarities, or flows? Are absent edges impossible, unknown, unmeasured, or simply outside scope?

These are not cosmetic choices. They determine the matrix and every result derived from it.

A network matrix is only as meaningful as the modeling definitions behind its rows and columns.

Back to top ↑

Adjacency Matrices

An adjacency matrix records whether nodes are connected. For an unweighted network, entry \(a_{ij}=1\) if node \(i\) is connected to node \(j\), and \(a_{ij}=0\) otherwise. For a weighted network, \(a_{ij}\) stores the edge weight.

For undirected networks, the adjacency matrix is symmetric. For directed networks, it may not be. For weighted networks, the magnitude of each entry matters. For sparse networks, most entries may be zero.

Adjacency matrices are powerful because they are simple. They are dangerous when the meaning of zero, weight, direction, or boundary is left implicit.

Back to top ↑

Weighted and Directed Networks

Many real networks are weighted and directed. A supply chain has direction. A citation network has direction. A transportation network may have asymmetric travel times. A power system may have capacity limits. A knowledge retrieval network may use similarity weights. A disease transmission network may use contact intensity or probability.

Weights and directions reshape interpretation. A node with many weak links may differ from a node with few strong links. A node with high outgoing influence may differ from a node with high incoming dependency. A link with high capacity may differ from a link with high risk, even if both are represented by large numbers.

The same number can mean strength, cost, risk, similarity, or probability. Responsible network modeling keeps that meaning attached to the matrix.

Back to top ↑

Incidence Structure and Flow

Adjacency matrices describe node-to-node connections. Incidence matrices describe node-to-edge relationships. They are especially useful for flows, conservation laws, graph Laplacians, optimization, and network constraints.

If \(\mathbf{f}\) is a vector of edge flows, then \(B\mathbf{f}\) describes net inflow or outflow at nodes, depending on sign convention. This supports conservation checks and imbalance detection.

Incidence matrices move network modeling from “who connects to whom” toward “how movement, balance, and constraints operate.”

Back to top ↑

Degree, Connectivity, and Reachability

Degree measures how many connections a node has, or the total weight of those connections. In directed networks, in-degree and out-degree must be separated. Connectivity asks whether nodes can reach one another. Reachability depends on paths, not only direct edges.

Matrix powers can help identify paths. The entry \((A^k)_{ij}\) counts or weights walks of length \(k\) under certain assumptions. This makes linear algebra a natural tool for multi-step connectivity analysis.

Connectivity metrics reveal structure, but the interpretation depends on whether edges represent physical routes, dependencies, probabilities, similarities, or influence.

Back to top ↑

Laplacians and Network Structure

The graph Laplacian connects network structure to linear algebra, geometry, diffusion, clustering, and spectral analysis. For an undirected network, the unnormalized Laplacian is the degree matrix minus the adjacency matrix.

Laplacians support community detection, smoothness analysis, diffusion modeling, graph signal processing, resistance distance, spectral clustering, and vulnerability analysis. The smallest eigenvalues are especially important for connectivity.

Spectral network analysis is mathematically powerful, but spectral patterns should not be overinterpreted without representation, scale, and domain review.

Back to top ↑

Centrality and Influence

Centrality metrics rank nodes according to specific definitions of importance. Degree centrality emphasizes direct connection. Eigenvector centrality emphasizes connection to other important nodes. Betweenness emphasizes brokerage across paths. Closeness emphasizes distance to others. PageRank-like methods emphasize recursively distributed influence.

No centrality metric measures importance in general. Each metric measures importance under assumptions.

Centrality is useful when communicated precisely: “central under this representation and metric,” not “important in every sense.”

Back to top ↑

Transition Matrices and Network Dynamics

Networks can also represent movement or state change. A row-normalized adjacency matrix can become a transition matrix if each row represents probabilities of moving from one node or state to another.

Once a transition matrix is defined, state vectors can evolve through matrix multiplication.

Transition matrices are useful when the network is not just connected but dynamic. They require careful interpretation because row normalization changes absolute weights into relative movement rules.

Back to top ↑

Vulnerability and Stress Testing

Network vulnerability analysis asks how structure changes when nodes, edges, capacities, or weights are disrupted. Linear algebra supports stress tests by perturbing matrices and recomputing connectivity, centrality, path structure, flow balance, or spectral diagnostics.

Stress testing helps reveal fragility, but it is not a prediction unless the disruption scenario, behavioral response, and validation evidence are credible.

Back to top ↑

Data Quality and Representation Risk

Network models are sensitive to missing edges, incorrect weights, boundary exclusions, temporal mismatch, aggregation, node duplication, inconsistent identifiers, and uncertain relationship meaning. These data issues can strongly affect centrality, connectivity, path, and vulnerability analysis.

A network model can look precise while depending on uncertain relationship data. Responsible workflows preserve uncertainty and provenance alongside the matrix.

Back to top ↑

Visualization and Interpretation

Network visualization is useful because structure is relational and often easier to inspect visually than through a matrix alone. But network diagrams can distort. Layout algorithms may imply distance, hierarchy, centrality, or clusters that are artifacts of visualization rather than evidence.

Visualization should support interpretation, not replace diagnostics. A good network graphic is paired with matrix definitions, metrics, assumptions, and uncertainty notes.

Back to top ↑

Mathematical Deepening

This section adds a more formal layer. Network system modeling connects adjacency matrices, incidence matrices, degree matrices, Laplacians, eigenvectors, transition matrices, centrality vectors, flow constraints, perturbation analysis, sparse computation, and responsible interpretation.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for network system modeling should document node definitions, edge definitions, weight meanings, directionality, boundary choices, data provenance, missing-edge rules, adjacency matrices, incidence matrices, degree vectors, Laplacians, centrality metrics, transition matrices, stress tests, vulnerability diagnostics, visualization choices, validation evidence, uncertainty, and interpretation boundaries.

The companion repository treats the network case study as an auditable 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 matrix construction, diagnostic computation, vulnerability analysis, and responsible interpretation.

For this article, the computational examples build a small weighted network, compute degree diagnostics, construct a Laplacian, evaluate a simple edge-removal scenario, and export a governance-ready audit report.

Back to top ↑

Python Workflow: Network System Modeling Audit

The Python workflow below constructs a small weighted undirected network, computes degree metrics, builds the graph Laplacian, performs an edge-removal stress test, and exports a structured audit record.

from __future__ import annotations

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


@dataclass(frozen=True)
class NetworkSystemAudit:
    workflow_name: str
    network_name: str
    node_count: int
    edge_count: int
    total_weight: float
    highest_weighted_degree_node: str
    highest_weighted_degree: float
    laplacian_trace: float
    baseline_component_count: int
    stressed_component_count: int
    removed_edge: str
    vulnerability_warning: str
    interpretation_warning: str


NODES = ["A", "B", "C", "D", "E"]

EDGES = [
    ("A", "B", 4.0),
    ("A", "C", 2.0),
    ("B", "C", 3.0),
    ("B", "D", 5.0),
    ("C", "D", 1.0),
    ("D", "E", 2.0),
]


def empty_matrix(n: int) -> list[list[float]]:
    return [[0.0 for _ in range(n)] for _ in range(n)]


def adjacency_matrix(edges: list[tuple[str, str, float]]) -> list[list[float]]:
    index = {node: i for i, node in enumerate(NODES)}
    A = empty_matrix(len(NODES))
    for u, v, weight in edges:
        i = index[u]
        j = index[v]
        A[i][j] = weight
        A[j][i] = weight
    return A


def weighted_degrees(A: list[list[float]]) -> list[float]:
    return [sum(row) for row in A]


def laplacian(A: list[list[float]]) -> list[list[float]]:
    degrees = weighted_degrees(A)
    L = empty_matrix(len(A))
    for i in range(len(A)):
        for j in range(len(A)):
            if i == j:
                L[i][j] = degrees[i]
            else:
                L[i][j] = -A[i][j]
    return L


def component_count(A: list[list[float]]) -> int:
    n = len(A)
    visited = [False] * n

    def dfs(start: int) -> None:
        stack = [start]
        while stack:
            node = stack.pop()
            if visited[node]:
                continue
            visited[node] = True
            for neighbor, weight in enumerate(A[node]):
                if weight > 0 and not visited[neighbor]:
                    stack.append(neighbor)

    count = 0
    for i in range(n):
        if not visited[i]:
            count += 1
            dfs(i)
    return count


def remove_edge(
    edges: list[tuple[str, str, float]],
    edge_to_remove: tuple[str, str],
) -> list[tuple[str, str, float]]:
    u0, v0 = edge_to_remove
    return [
        (u, v, weight)
        for u, v, weight in edges
        if {u, v} != {u0, v0}
    ]


def build_audit() -> NetworkSystemAudit:
    A = adjacency_matrix(EDGES)
    degrees = weighted_degrees(A)
    L = laplacian(A)

    highest_index = max(range(len(NODES)), key=lambda i: degrees[i])
    total_weight = sum(weight for _, _, weight in EDGES)

    stressed_edges = remove_edge(EDGES, ("B", "D"))
    A_stressed = adjacency_matrix(stressed_edges)

    baseline_components = component_count(A)
    stressed_components = component_count(A_stressed)

    return NetworkSystemAudit(
        workflow_name="network_system_modeling_audit",
        network_name="synthetic_infrastructure_service_network",
        node_count=len(NODES),
        edge_count=len(EDGES),
        total_weight=round(total_weight, 12),
        highest_weighted_degree_node=NODES[highest_index],
        highest_weighted_degree=round(degrees[highest_index], 12),
        laplacian_trace=round(sum(L[i][i] for i in range(len(L))), 12),
        baseline_component_count=baseline_components,
        stressed_component_count=stressed_components,
        removed_edge="B-D",
        vulnerability_warning=(
            "The edge-removal scenario changes network structure under one simplified stress test. "
            "It does not predict real failure behavior without capacity, timing, redundancy, and domain validation."
        ),
        interpretation_warning=(
            "Network metrics depend on node definitions, edge meanings, weights, directionality, boundary choices, "
            "and missing-edge assumptions. Centrality and vulnerability should be interpreted only within that representation."
        ),
    )


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)
    (output_dir / "reports").mkdir(parents=True, exist_ok=True)

    audit = build_audit()
    row = asdict(audit)

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

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

    report = [
        "# Network System Modeling Audit",
        "",
        f"- Workflow: {audit.workflow_name}",
        f"- Network: {audit.network_name}",
        f"- Node count: {audit.node_count}",
        f"- Edge count: {audit.edge_count}",
        f"- Total edge weight: {audit.total_weight}",
        f"- Highest weighted-degree node: {audit.highest_weighted_degree_node}",
        f"- Highest weighted degree: {audit.highest_weighted_degree}",
        f"- Laplacian trace: {audit.laplacian_trace}",
        f"- Baseline component count: {audit.baseline_component_count}",
        f"- Stressed component count: {audit.stressed_component_count}",
        f"- Removed edge: {audit.removed_edge}",
        "",
        audit.vulnerability_warning,
        "",
        audit.interpretation_warning,
    ]

    (output_dir / "reports" / "network_system_modeling_audit.md").write_text(
        "\\n".join(report) + "\\n",
        encoding="utf-8",
    )


if __name__ == "__main__":
    write_outputs(Path("outputs"))
    print("Network system modeling audit complete.")

This workflow keeps the network metric, stress-test scenario, and interpretation warning together as one auditable artifact.

Back to top ↑

R Workflow: Network Metrics and Vulnerability Review

R can support the same case study by constructing a weighted adjacency matrix, computing degree metrics, forming the Laplacian, and exporting the audit record.

nodes <- c("A", "B", "C", "D", "E")

edges <- data.frame(
  from = c("A", "A", "B", "B", "C", "D"),
  to = c("B", "C", "C", "D", "D", "E"),
  weight = c(4.0, 2.0, 3.0, 5.0, 1.0, 2.0)
)

build_adjacency <- function(nodes, edges) {
  A <- matrix(0, nrow = length(nodes), ncol = length(nodes))
  rownames(A) <- nodes
  colnames(A) <- nodes

  for (i in seq_len(nrow(edges))) {
    u <- edges$from[i]
    v <- edges$to[i]
    w <- edges$weight[i]
    A[u, v] <- w
    A[v, u] <- w
  }

  A
}

component_count <- function(A) {
  n <- nrow(A)
  visited <- rep(FALSE, n)

  dfs <- function(start) {
    stack <- c(start)
    while (length(stack) > 0) {
      node <- stack[length(stack)]
      stack <- stack[-length(stack)]
      if (!visited[node]) {
        visited[node] <<- TRUE
        neighbors <- which(A[node, ] > 0)
        stack <- c(stack, neighbors[!visited[neighbors]])
      }
    }
  }

  count <- 0
  for (i in seq_len(n)) {
    if (!visited[i]) {
      count <- count + 1
      dfs(i)
    }
  }

  count
}

A <- build_adjacency(nodes, edges)
degrees <- rowSums(A)
L <- diag(degrees) - A

stressed_edges <- subset(
  edges,
  !((from == "B" & to == "D") | (from == "D" & to == "B"))
)

A_stressed <- build_adjacency(nodes, stressed_edges)

audit_record <- data.frame(
  workflow_name = "network_system_modeling_audit",
  network_name = "synthetic_infrastructure_service_network",
  node_count = length(nodes),
  edge_count = nrow(edges),
  total_weight = sum(edges$weight),
  highest_weighted_degree_node = names(which.max(degrees)),
  highest_weighted_degree = max(degrees),
  laplacian_trace = sum(diag(L)),
  baseline_component_count = component_count(A),
  stressed_component_count = component_count(A_stressed),
  removed_edge = "B-D",
  vulnerability_warning = paste(
    "The edge-removal scenario changes network structure under one simplified stress test.",
    "It does not predict real failure behavior without capacity, timing, redundancy, and domain validation."
  ),
  interpretation_warning = paste(
    "Network metrics depend on node definitions, edge meanings, weights, directionality,",
    "boundary choices, and missing-edge assumptions."
  )
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)
write.csv(
  audit_record,
  "outputs/tables/r_network_system_modeling_audit.csv",
  row.names = FALSE
)

print(audit_record)

This R workflow emphasizes that network diagnostics should be exported with scenario and interpretation warnings, not only numerical metrics.

Back to top ↑

Haskell Workflow: Typed Network Audit

Haskell can represent network diagnostics as a typed record, preserving node counts, edge counts, stress-test results, and interpretation warnings as part of the output.

module Main where

data NetworkSystemAudit = NetworkSystemAudit
  { workflowName :: String
  , networkName :: String
  , nodeCount :: Int
  , edgeCount :: Int
  , totalWeight :: Double
  , highestWeightedDegreeNode :: String
  , highestWeightedDegree :: Double
  , laplacianTrace :: Double
  , baselineComponentCount :: Int
  , stressedComponentCount :: Int
  , removedEdge :: String
  , vulnerabilityWarning :: String
  , interpretationWarning :: String
  } deriving (Show)

buildAudit :: NetworkSystemAudit
buildAudit =
  NetworkSystemAudit
    "network_system_modeling_audit"
    "synthetic_infrastructure_service_network"
    5
    6
    17.0
    "B"
    12.0
    34.0
    1
    1
    "B-D"
    "The edge-removal scenario is a simplified stress test and does not predict real failure behavior without validation."
    "Network metrics depend on node definitions, edge meanings, weights, directionality, boundaries, and missing-edge assumptions."

main :: IO ()
main =
  print buildAudit

The typed record keeps vulnerability and interpretation warnings attached to the numerical result.

Back to top ↑

SQL Workflow: Network Governance Registry

SQL can document network modeling assumptions when network workflows support repositories, dashboards, audits, or institutional decision systems.

CREATE TABLE network_modeling_governance_registry (
    governance_key TEXT PRIMARY KEY,
    governance_name TEXT NOT NULL,
    modeling_role TEXT NOT NULL,
    review_requirement TEXT NOT NULL,
    responsible_use_warning TEXT NOT NULL
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'node_definition',
  'Node definition',
  'Defines what each row and column in the network matrix represents.',
  'Document whether nodes are facilities, regions, agents, documents, states, sectors, or components.',
  'Centrality and vulnerability metrics are not meaningful if node types are unclear or mixed without justification.'
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'edge_definition',
  'Edge definition',
  'Defines what a relationship means in the network.',
  'Document whether edges represent flow, dependency, similarity, communication, probability, cost, or influence.',
  'A connection does not automatically imply causality, authority, capacity, or reliability.'
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'weight_semantics',
  'Weight semantics',
  'Defines how edge magnitudes should be interpreted.',
  'State whether larger weights mean stronger, cheaper, riskier, more likely, more costly, or more capacious relationships.',
  'Weight meaning must be clear before ranking, optimizing, or comparing network structure.'
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'directionality',
  'Directionality',
  'Defines whether links are symmetric or directional.',
  'Document whether adjacency matrices are symmetric and whether in-degree and out-degree require separate interpretation.',
  'Undirected simplification can hide asymmetric dependency or influence.'
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'boundary_scope',
  'Boundary scope',
  'Defines which nodes, edges, and external dependencies are included or excluded.',
  'Maintain a boundary register with omitted nodes, omitted edges, and external support assumptions.',
  'Network vulnerability may be underestimated when external dependencies are excluded.'
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'centrality_interpretation',
  'Centrality interpretation',
  'Connects centrality metrics to specific definitions of importance.',
  'Report which centrality metric was used and why it matches the modeling purpose.',
  'Centrality means importance only under the chosen representation and metric.'
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'stress_testing',
  'Stress testing',
  'Compares matrix outputs under node, edge, weight, or boundary perturbations.',
  'Document stress scenarios, removed elements, and scenario assumptions.',
  'Stress tests are scenario analyses, not predictions, unless validated against real failure behavior.'
);

INSERT INTO network_modeling_governance_registry VALUES
(
  'visualization_limits',
  'Visualization limits',
  'Defines how network graphics should be interpreted.',
  'State whether layout is geographic, algorithmic, schematic, or metric-based.',
  'Graph layout can visually imply structure not supported by the model.'
);

SELECT
    governance_name,
    modeling_role,
    review_requirement,
    responsible_use_warning
FROM network_modeling_governance_registry
ORDER BY governance_key;

This registry keeps network modeling assumptions visible across node definitions, edge definitions, weights, directionality, boundaries, centrality, stress tests, and visualization limits.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible network modeling workspace. It supports adjacency matrix construction, incidence structure, degree diagnostics, Laplacian analysis, centrality review, transition matrix preparation, edge-removal stress tests, vulnerability diagnostics, governance tables, generated artifacts, advanced audit reports, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Network system modeling is powerful because it reveals structure that is invisible when components are viewed separately. It can show connection, dependence, redundancy, bottlenecks, flow, reachability, centrality, diffusion, vulnerability, and dynamic movement across systems.

Its limits are equally important. A network is not the full system. Nodes simplify entities. Edges simplify relationships. Weights simplify capacities, risks, costs, probabilities, or similarities. Graph metrics depend on representation choices. Visual layouts can mislead. Stress tests are scenarios, not predictions. Centrality is metric-specific, not universal importance.

Responsible network modeling requires documenting node meaning, edge meaning, weight semantics, directionality, boundary choices, missing-data assumptions, matrix construction, diagnostics, validation evidence, uncertainty, visualization choices, and interpretation boundaries. A good network model does not merely produce scores; it explains what those scores can and cannot responsibly support.

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
• Flow, Connectivity, and System Vulnerability
• State Transition Models and System Dynamics
• Scaling, Normalization, and Comparative Structure
• Interpretation, Approximation, and Responsible Mathematical Modeling
• Case Study: Infrastructure Interdependence
• Case Study: Economic Input-Output Analysis
• Systems Modeling
• Mathematical Modeling
• Scientific Computing for Systems Modeling

Back to top ↑

Further Reading

• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Bollobás, B. (1998) Modern Graph Theory. New York: Springer. Available at: https://doi.org/10.1007/978-1-4612-0619-4.
• Buldyrev, S.V. et al. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Chung, F.R.K. (1997) Spectral Graph Theory. Providence, RI: American Mathematical Society. Available at: https://bookstore.ams.org/cbms-92.
• Golub, G.H. and Van Loan, C.F. (2013) Matrix Computations. 4th edn. Baltimore, MD: Johns Hopkins University Press. Available at: https://jhupbooks.press.jhu.edu/title/matrix-computations.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• Newman, M.E.J. (2010) Networks: An Introduction. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780199206650.
• Spielman, D.A. (2019) Spectral and Algebraic Graph Theory. Yale University lecture notes. Available at: https://cs-www.cs.yale.edu/homes/spielman/sagt/.
• Strang, G. (2019) Linear Algebra and Learning from Data. Wellesley, MA: Wellesley-Cambridge Press. Available at: https://math.mit.edu/~gs/learningfromdata/.
• Wasserman, S. and Faust, K. (1994) Social Network Analysis: Methods and Applications. Cambridge: Cambridge University Press. Available at: https://doi.org/10.1017/CBO9780511815478.

Back to top ↑

References

• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
• Bollobás, B. (1998) Modern Graph Theory. New York: Springer. Available at: https://doi.org/10.1007/978-1-4612-0619-4.
• Buldyrev, S.V. et al. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://doi.org/10.1038/nature08932.
• Chung, F.R.K. (1997) Spectral Graph Theory. Providence, RI: American Mathematical Society. Available at: https://bookstore.ams.org/cbms-92.
• Golub, G.H. and Van Loan, C.F. (2013) Matrix Computations. 4th edn. Baltimore, MD: Johns Hopkins University Press. Available at: https://jhupbooks.press.jhu.edu/title/matrix-computations.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780198805090.
• Newman, M.E.J. (2010) Networks: An Introduction. Oxford: Oxford University Press. Available at: https://global.oup.com/academic/product/networks-9780199206650.
• Spielman, D.A. (2019) Spectral and Algebraic Graph Theory. Yale University lecture notes. Available at: https://cs-www.cs.yale.edu/homes/spielman/sagt/.
• Strang, G. (2019) Linear Algebra and Learning from Data. Wellesley, MA: Wellesley-Cambridge Press. Available at: https://math.mit.edu/~gs/learningfromdata/.
• Wasserman, S. and Faust, K. (1994) Social Network Analysis: Methods and Applications. Cambridge: Cambridge University Press. Available at: https://doi.org/10.1017/CBO9780511815478.

Back to top ↑