---
title: Graph Models for a Real-Time Cooling Simulation
description: Simulating a nuclear facility cooling system with graph traversal, matrix solving, Flask, NumPy, and real-time monitoring clients.
date: 2026-05-04
projectPeriod: 'October-November 2018'
thumbnail:
  src: ./_assets/process-simulator.jpg
  alt: Cooling system simulator interface with pipes, pumps, and temperature values.
tags: ['simulation', 'systems', 'tools']
selected: true
featuredOrder: 6
project: nuclear-simulation
role: Simulation and UI author
stack: ['Python', 'Flask', 'NumPy', 'HTML canvas', 'JavaFX']
scale: Remote simulation server with multiple monitoring clients and a separate graph editor
outcome: A believable, extensible cooling-system simulation for a cybersecurity challenge context
audience: recruiter-relevant
links: []
media:
  - type: image
    src: ./_assets/process-simulator.jpg
    alt: Screenshot of the cooling system simulator with pipes, pumps, coolers, and temperature values.
    caption: The simulator calculated flow and temperature over graph-based process models.
  - type: image
    src: ./_assets/process-simulator-input.jpg
    alt: Screenshot of the JavaFX graph editor used to define simulator input.
    caption: A separate JavaFX editor produced JSON inputs for the simulation backend.
---

This project simulated the cooling system of a nuclear facility. It was built for a cybersecurity challenge about PLCs, where participants needed to see the consequences of changing a system state.

The simulation did not try to be physically complete. It aimed to be cheaply calculated, believable to a non-specialist, scalable enough for the event context, and understandable through a clean GUI.

## The Problem

The simulated system needed reactors, coolers, pumps, heat exchangers, drains, sources, and pipes. Those elements had to be configurable, and multiple monitoring clients needed to update in real time from a remote server.

The key challenge was representing flow and temperature in a way that was simple enough to calculate repeatedly but structured enough to produce plausible behavior.

## Design

The system used two graph models. First, water was distributed by traversing the graph of pipes according to pressures generated by pumps. Then, an adjacency matrix was populated from the relations between nodes based on water flow.

After accounting for base temperatures, heaters, and heat exchangers, the matrix was solved to calculate current node temperatures. Repeating that process advanced the simulation.

Python handled the backend logic with Flask and NumPy. The monitoring frontend used an HTML5 canvas. A separate JavaFX graph editor let users move nodes, edit element parameters, export JSON, and upload inputs to the backend.

## What Worked

The graph/matrix split was a useful modeling boundary. Flow and heat exchange are related, but treating them as separate calculation phases kept the implementation easier to reason about.

The editor also mattered. A simulation is much more useful when its input is inspectable and editable by people who are not editing source files.

## What I Would Change

Today I would formalize the model limitations more clearly. A convincing simulation can be useful, but it should say exactly what it does and does not claim.

I would also add recorded scenarios and regression tests. Simulation projects are vulnerable to accidental behavior changes that still look plausible on screen.
