Add project writeups

src/content/posts/nuclear-cooling-simulation.md

@@ -0,0 +1,56 @@
+---
+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']
+featuredOrder: 5
+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 behaviour.
+
+## 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 modelling 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 formalise 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 behaviour changes that still look plausible on screen.