Go to the Live Ax3l Site to see more!
]]>
Go to the Live Ax3l Site to see more!
]]>
BMDynIP is a dynamic DNS service for people who:
BMDynIP uses the GoDaddy CLI tool to manage DNS A records for one or more hostnames, such as www.osoyalce.com. It keeps those records pointed at your current public IP address.
The service:
Here’a screenshot of the web interface.
Things became digital. The cost of storage plummeted and so I started keeping digital copies all of the movies or TV shows that I liked. Why? Because I do rewatch things and I like collecting, and this seemed harmless.
And I thought, “Great! This will de-clutter my life, now all I have to do is organize a bunch of files!” I got rid of my DVDs and embraced the digital lifestyle.
That was about 25 years ago. Now I have over a thousand movies, almost 200 TV shows, and seasons, and seasons, and seasons of episodes.
I tried to mostly keep things organized, renaming files and folders to keep things sane. I did a pretty decent job, but the sheer volume meant that over time finding or browsing was becoming more and more difficult, until it basically became impossible. There were just too many directories.
The solution was obvious.
Creating a catalogue entry at the same time seemed natural.
The Movie Database has a free, publicly available database of movie and TV titles, including poster art, episode descriptions, casts, and more. I could use that to create a really nice catalogue entry for my movies.
There was absolutely no way I was going to do this by hand.
Writing software to handle all of the special cases was daunting. Tons of weird filenames and matching that to a TMDB entry would be super hard. Frankly, it was out of reach for me.
What I really needed was an intern, or a gopher (Go ‘fer that), or a robot to go through the directories one at a time.
I had just the thing! I’d recently downloaded Qwen 3.5 4B a small LLM, like ChatGPT, but running on my own computer. It was smart enough to handle the job.
I had just finished building Ax3l, an autonomous AI agent that was running thousands of simulations to tune a simple neural network. It turned a knob, ran a simulation, studied the results, turned a knob, ran a simulation…
This project was simple by comparison. I’d have the LLM:
I named the project R3el and started designing.
Okay, not simple, but definitely something I could create using the Ax3l codebase as a starting point.
I knew I’d eventually build a catalogue with a web interface to browse and search my collection, so I figured I might as well leverage that and build a control interface there.
My experience working with LLMs taught me the value of fine-grained reporting. Again, I leaned on the Ax3l codebase and created a detailed Event Log so I could monitor, tune, and troubleshoot the process.
It took me most of one day to itemize and label all of the messages I was interested in, but it was an excellent investment and significantly helped focus my development efforts.
It took some tuning; I added use cases, I improved the pattern matching, and I did a minimal amount of manual work sweeping through the filesystem. But it worked!!! For the next few days, I’d queue up a batch of directories and let it work.
The last step was to build a nice browse and search interface:
This part was easy, there are so many examples of user interfaces that provide this sort of functionality. Building a simple one was straightforward.
The project is done. R3el is still scanning, but I think it’ll finish by end of day. Early on I wondered if building this was overkill, but realistically, this is the only way I can still think of to tackle a massive data cleanup exercise like this.
And it’s pretty cool, right! :)
But by the time I was finished with Fr3d, I had also learned exactly how I didn’t want to build the next version.
The code had grown organically around the experiment. Prompts were embedded in the application. Responsibilities overlapped. Logging told me what the program was doing, but not necessarily why. Making changes meant tracing through code that had accumulated along with the ideas.
Fr3d was a successful prototype.
Ax3l was the rewrite.
With Ax3l, I started from the architectural lessons Fr3d had taught me.
The prompting system became modular and data-driven. Different kinds of interactions with the LLM became distinct prompt classes. Experiment data, prompt construction, simulation control, and reporting became separate concerns.
More importantly, I treated observability as part of the application rather than something I could bolt on later.
Ax3l got its own reporting server and a new event logging system backed by the database. Events were organized into categories and subcategories, and the logs themselves became interactive.
Instead of seeing something like:
Simulation completed.
I could click into that event and inspect the simulation, its configuration, the prompt that produced it, the model’s reasoning, and the resulting data.
The logs stopped being a stream of text.
They became a way of navigating the experiment.
That turned out to matter enormously. Ax3l wasn’t going to run one experiment while I watched. It was going to run hundreds of them, unattended, over days and eventually weeks. If I wanted to understand what the AI was doing, I needed to be able to reconstruct its decisions afterwards.
At some point, rows of numbers stopped being enough.
The Snake Lab already knew when a game had achieved a new high score, so I modified it to capture the board state at that moment and store it along with the simulation results.
I then exposed that snapshot through the Snake Lab’s ZeroMQ API.
Now Ax3l could retrieve the actual board corresponding to the best game from a simulation and display it in the report.
Suddenly, a score of 47 wasn’t just 47.
There was the snake.
You could see the path it had taken, how long it had become, where the food was, and the state of the board when it achieved that score.
It was a small addition technically, but it changed the personality of the project. The experiment wasn’t just producing database records anymore. There was a little AI snake in there, getting better at its job.
No snakes were harmed in this experiment, although many virtual snakes made questionable life choices!
A high score alone is a terrible way to answer that question.
Reinforcement learning is noisy. A configuration can get lucky. One spectacular run doesn’t necessarily mean the underlying system has improved.
So I added a histogram showing the distribution of scores across simulations.
Then I added an overlay.
The histogram for the oldest half of the experiment is drawn over the histogram for all of the data. Because the older dataset is a subset of the complete one, its bars can only be equal to or shorter than the corresponding bars for the full experiment.
If Ax3l isn’t accomplishing anything, the additional results should simply pile onto roughly the same distribution.
But if the experiment is working, something much more interesting happens.
The distribution starts creeping to the right.
You can see the experiment learning its way into better regions of the configuration space.
That visualization became much more useful to me than watching a single high-score number tick upwards.
The original working Snake configuration could achieve a high score of about 38.
I knew from my previous experiments that the RNN could do better than that. The question was whether an LLM, given the right tools, history, and experimental framework, could systematically find those better configurations.
At the time of writing, Ax3l has passed 500 simulations.
The current high score is 53.
More importantly, the score distribution has moved.
Ax3l isn’t simply throwing darts until one happens to hit 53. Across the experiment, the population of results has shifted towards better-performing configurations.
And the experiment is still running.
There was one final problem.
Ax3l’s reporting server was excellent when I was sitting on my own network, but I wanted the experiment itself to be visible publicly.
I didn’t want to expose the production database or application server to the Internet just to publish some graphs.
So I built one last small project: Snake Web.
Every half hour, Snake Web queries the experiment database and generates a set of CSV files containing the data needed by a static GitHub Pages site. Those files are published, and the public site updates with the latest state of the experiment.
The high scores are there.
The histograms are there.
The individual simulation results are there.
Even the seed rotations are visible. When Ax3l moves to a new random seed and performance suddenly drops, the graph faithfully falls off a cliff and begins climbing again.
It’s not a polished-up retrospective showing only the successful bits.
It’s the experiment, scars and all.
And with that, I think the project is finished.
Not because there aren’t another hundred things I could add. There always are.
It’s finished because the system I originally wanted now exists.
There is a dedicated reinforcement-learning laboratory that runs controlled Snake experiments and records their results.
There is an autonomous LLM agent that examines those results, reasons about them, chooses new configurations, and submits further experiments.
There is an observability layer that lets me inspect what it did and why.
There is a public pipeline that publishes the experiment’s progress without exposing the machinery running underneath it.
And somewhere inside all of that architecture, databases, ZeroMQ messages, prompts, PyTorch tensors, CSV files, and graphs is a snake that used to score 38.
Now it scores 53.
That’s a pretty good place to stop.
What happens if I let an LLM drive it?
That became Fr3d.
Fr3d was my first attempt at building an autonomous agent around Snake Lab. The basic idea was fairly simple. Give the model enough information about the experiment, show it the current configuration and the results of previous runs, then ask it to choose a new configuration that might perform better.
Snake Lab would run the experiment.
Fr3d would look at the result.
Then it would try again.
In other words, I had finally connected the little local LLM experiment from my previous post to something that could actually do work.
I started building prompts that explained the Snake experiment to the model.
The prompt described the neural network, the available parameters, their valid ranges, the current configuration, and whatever experimental history seemed relevant. Fr3d would then choose a parameter value and submit a new experiment through the Snake Lab API.
The whole thing formed a loop:
prompt → LLM → configuration → Snake Lab → result → prompt
And surprisingly quickly, it worked.
Not beautifully.
But it worked.
I already had a known working Snake configuration that could produce a high score of around 38, and I knew from months of manually experimenting with the RNN that better configurations existed. So Fr3d had a real problem to solve.
This wasn’t just asking an LLM to produce plausible-looking JSON.
It had to make decisions against actual experimental results.
Around this time I took a short detour into Qwen 2.5 VL, the vision-language version of the model.
The idea was appealing.
Instead of describing everything numerically, perhaps I could show the model plots or even images from the Snake experiments and let it reason visually about what was happening. It worked technically, but I quickly ran into a more important problem.
The vision model simply wasn’t as good at reasoning as Qwen 3.5. For this particular application, that mattered much more than vision.
Qwen 3.5 also exposed its reasoning process, which turned out to be incredibly useful while developing the prompts. I could see what the model thought I was asking it to do. And sometimes it was very clearly telling me:
“This prompt is nonsense.”
Not literally, perhaps, but effectively.
I would ask it to choose an unused parameter value and then discover, through its reasoning, that every valid value had already been used. Or I would omit some piece of experimental history that the model obviously needed. Or I would give it information in a structure that made perfect sense to me, but left the model struggling to determine which values were actually comparable.
Watching the reasoning made those failures visible.
That was probably my first real lesson in prompt engineering. A bad answer isn’t necessarily a model problem.Sometimes you’ve simply built a bad question.
Before Fr3d, I had mostly thought about prompts as instructions. By the end of the project I was thinking about them much more like interfaces.
The model can only reason over the information you give it. The structure of that information matters. The terminology matters. The constraints matter. The history you include matters.
If you tell the model to select a value from a search space, it needs to know the search space. If it must avoid previously tested values, it needs a reliable record of those values. If results from different seeds aren’t directly comparable, the prompt needs to make that distinction clear. And if the prompt contains contradictory requirements, the LLM is going to have exactly the same problem a programmer would have working from a contradictory specification.
The prompts became part of the system architecture.
After about a week, Fr3d was working.
And the code was horrible.
Not because any individual part was especially complicated. It had simply grown organically while I was figuring out what the system needed to be and how to work with the low level code.
It had reached that familiar prototype stage where the software technically worked, but understanding *why- it worked was becoming increasingly difficult. And that was when I realized something else I had gotten wrong.
I had treated logging and reporting as things I could add around the experiment. That was backwards. For an autonomous experimental system, observability is part of the experiment. I needed to be able to answer basic questions easily:
A pile of log files could technically answer those questions. But technically answering a question and making the system understandable are very different things. The next system needed to be designed around reporting from the beginning.
Fr3d also taught me where the natural module boundaries were.
Some parts of the system were generic:
Other parts were specific to this particular experiment:
Those two categories had become tangled together in Fr3d. Once I could see that distinction clearly, the architecture of the next version became much more obvious.
There is always a temptation with a working prototype to keep repairing it. Refactor this piece. Move that function. Extract a class. Clean up a prompt. Remove some duplication.
I decided not to.
Fr3d had already done its job. It had proven that the idea worked. More importantly, it had shown me where the difficult parts actually were. That is enormously valuable information, and it is information that is very difficult to get by designing everything perfectly in advance. So I kept the lessons and threw away the architecture.
My takeaway from Fr3d was not design everything correctly before you begin. Almost the opposite.
Fr3d was messy. But it worked. And because it worked, I finally knew what I needed to build next.
It worked.
I had a machine in my basement writing poetry about random numbers.
Naturally, the next question was: what else can I get this thing to do?
While I was experimenting with the model, I discovered that it knew about Patrick Loeber’s AI Snake Game experiment. That caught my attention because I knew that experiment very well. I had been playing with and modifying that code for quite some time.
And that gave me an idea.
What if, instead of asking the LLM to write haikus, I gave it the results of a Snake simulation?
I could give it the configuration that produced those results, ask it to reason about them, and then ask it to produce a new configuration. I could run that configuration through the simulator, collect the results, feed them back to the LLM, and repeat.
In other words:
Could I get an LLM to optimize another AI?
That idea would eventually become Fr3d.
But there was a problem.
I had followed Patrick Leober’s tutorial, and then I continued. I ported it into Textual and integrated the old MatPlotLib plots with integrated Textual Plot plots. The application became separate client and server processes. ZeroMQ connected them. Simulation results were stored in a database.
The Textual client could configure a simulation, send that configuration to the server, start a run, and monitor it while it was running.
It was already much more than a Snake game.
But it was still an application. Its architecture had grown around the assumption that a human being was sitting at the client and conducting experiments.
Fr3d changed that assumption.
I took the existing Snake code and split off a new, independent project: Snake Lab Server.
The basic idea was simple. Snake Lab Server wouldn’t care who was conducting the experiment.
A client would submit a JSON configuration over ZeroMQ. The server would validate it, queue the experiment, run the simulation, collect the metrics, and store the results in MariaDB.
The server itself would run as a systemd service.
That meant an LLM could use it. A Python script could use it. A terminal application could use it. Something I haven’t thought of yet could use it.
The simulator didn’t need to know.
I also ported my Textual client to the new system. I still wanted to be able to submit experiments myself and, more importantly, watch them run.
There is something considerably more satisfying about actually seeing the snake moving around the board than watching numbers scroll past in a log file.
But now the Textual interface was just one client.
That was an important distinction.
I also wanted Snake Lab Server to be fairly strict about what constituted an experiment.
The configuration is validated before a simulation is accepted. The configuration used for the run is recorded. The results are recorded. Metrics are collected throughout the simulation, including per-game and per-episode data.
That matters because I wasn’t interested in simply asking:
Did this snake get a better score?
I wanted to be able to ask:
What exactly did we run, and what happened?
If an automated system was eventually going to conduct hundreds of experiments, I needed the answer to that question to survive long after the experiment had finished.
Otherwise I wouldn’t have a laboratory.
I’d have a slot machine.
And that was Snake Lab Server.
It wasn’t Fr3d yet.
There was no autonomous LLM scientist examining results, reasoning about configurations, and deciding what experiment to run next. That part still had to be built.
But now there was somewhere for it to work.
I had started with an AI learning to play Snake. That had evolved into a client/server application for experimenting with it. And now that application had evolved again, into a service designed specifically so that other software could conduct controlled experiments on the Snake AI.
The laboratory was ready.
Now I needed to build the scientist.
I recently acquired a pair of matching HP Z440 workstations with M4000 GPUs. I did some research and learned that I could run a small local LLM on that hardware. I’ve only ever engaged with LLMs as an end-user, in my browser or in my VS code editor.
So I downloaded the Qwen3.5 4B model from Hugging Face and started figuring out how to run it using llama.cpp.
Getting everything running involved a few pieces.
I downloaded the Qwen model from Hugging Face and the llama.cpp source code. From there I built the intermediate model and eventually converted it into the GGUF format used by llama.cpp. The process was technical, but straightforward. The longest part wa the 18 Gb download.
Then, I fired up llama_server, pointed my browser at it and…
There it was.
A web page with a chat box.
I had built myself a chatbot.
That was simultaneously very cool and not particularly interesting.
I already had ChatGPT, which is a LOT more knowledgeable and skilled.
Of course, the first thing I did was start asking it questions.
I asked it some general knowledge questions. It knew historical figures (e.g. Rudolf Steiner), geography, science. Coding…
The answer was: quite a lot.
That was impressive in itself. This wasn’t reaching out to Google or calling some giant AI service on the Internet. The model and everything it knew were sitting right there on my own machine.
Then I asked it about Patrick Loeber’s AI Snake tutorial.
It knew what I was talking about.
That got my attention.
Patrick Loeber’s project was familiar territory for me. My own Snake Lab project grew out of experimenting with an AI learning to play Snake, so suddenly I wasn’t asking the model trivia questions anymore. I could talk to it about something I actually knew.
And it could talk back intelligently.
That was cool.
The problem was that I still had a chatbot.
I could ask it questions. It could answer them. That was impressive, but it wasn’t really what interested me.
I wanted to use the LLM from code.
So I wrote a crude conversation loop.
There wasn’t any grand plan at this point. I just wanted a program that could send a prompt to the model, get a response back, and do something with it.
Which raised an important engineering question:
What should I ask it to do?
Apparently my answer was:
Write haikus about numbers.
The program generated a random number and sent it to the LLM with a prompt asking it to write a haiku about that number.
The LLM wrote the haiku.
The program wrote the result to a log file.
A new age starts today
Apollo touches the moon's face
New world begins to shine
1970
Then it generated another number.
And another.
And another.
Soon I had a locally hosted Large Language Model sitting on my computer, contemplating random integers and writing poetry about them.
It wasn’t exactly useful.
But it worked.
The important part wasn’t the haiku. The important part was the loop:
For the first time, I wasn’t really talking to an AI.
I had put an AI inside a program.
My first experiment with a locally hosted LLM produced absolutely nothing of practical value.
It wrote haikus about random numbers.
But that little experiment answered the question I actually cared about.
I could run an LLM locally. I could communicate with it from my own software. I could give it information, get a response, record that response and repeat the process without sitting in front of a chat window.
At that point I didn’t have Ax3l.
I didn’t even have the idea fully formed.
I had a loop.
And a log file full of haikus.
The current architecture has three main pieces:
The broker is the center of gravity. It fetches market data through OANDA, stores candle data in an in-memory SQLite database, and publishes updates to clients through ZeroMQ.
The Qt client connects to the broker, subscribes to a candlestick topic, and updates the interface as new data arrives. The result is a small live market console: recent candles in a table, a candlestick chart underneath, instrument selection, broker and OANDA latency.
That last part matters. This project is not just about making a chart move. It is about building a system that can observe itself.
One thing I wanted to avoid was turning the GUI into the trading system.
The GUI is useful for making selections, for rendering, resizing, tables, charts, buttons and more, but that is not where the data feed should be managed.
The broker gives the project a clean separation:
That separation is already paying off. The Qt client can disconnect and reconnect without being the source of truth. The broker can keep doing broker things. The GUI can keep doing GUI things.
The latest milestone is the Qt interface. I was initially going to use Textual for the client, but when I saw Plotly’s candlestick plots I decided I needed that. The AIFX client uses Qt for Python, renders Plotly charts in a QtWebEngineCore, and
The client now opens with historical candles already loaded, so the screen does not start empty while waiting for fresh data. Instrument switching works. The recent candle table updates. The chart updates. Status labels show broker and OANDA call latency.
That may sound cosmetic, but it changes the feel of the project.
A console log tells you the machinery is alive. A live chart makes it obvious.
It also surfaces problems faster. Missing candles, stale subscriptions, latency spikes, formatting issues, and feed timing quirks all become visible. The GUI is not just eye candy. It is a diagnostic cockpit.
AI FX is currently focused on five-second candles.
That is a small enough interval to make the system feel alive, but still structured enough to work with as discrete data. Each candle becomes a compact summary of a tiny slice of market activity: open, high, low, close, volume, and timestamp.
For now, the project is still in the infrastructure phase. The work is not about pretending the system is ready to trade. It is about building the rails:
The trading logic can come later. The wiring and plumbing come first.
A surprising amount of progress has come from the unglamorous parts.
There are unit tests now for core data classes like instruments and candles. There is a release process. There are linting and typing checks. There is a fresh-install smoke test path to make sure the package works outside the development tree.
That matters because this kind of project can become a spaghetti aquarium very quickly.
Market data, networking, async loops, GUI events, serialization, plotting, packaging, and API calls all want to tangle themselves together. Tests and release discipline are the small fences that keep the goats out of the server room.
AI FX is still a small machine.
It is not an institutional trading platform. It is not a magic money machine. It is not trying to outrun colocated infrastructure or pretend retail latency does not exist.
But it is becoming a useful lab.
The original idea was to build something small enough to understand and flexible enough to experiment with. That is still the goal.
The seed is no longer just in the ground.
There is a signal now.
]]>pgm-ds), where the DS is Data Science.
The pgm-ds project extends the Power Grid Model. From their docs, “power-grid-model is a library for steady-state distribution power system analysis.” Its model includes components for:
-and more. It’s used to model power flow, state estimation, and short circuits.
The Power Grid Model DS builds on top of this to provide a clean and easy-to-use API to model and simulate the behaviour of the grid. “This is aimed at building data science software applications related to or using the power-grid-model project, such as network analyses and simulations. It defines a Grid dataclass which manages the consistency of the complete network and allows for extensions of the Power Grid Model datastructure.”
The mechanics were straightforward; the meaning took effort.
The pgm-ds is easy to use. It was relatively trivial to take their Jupyter notebook-style docs and create a script to run the demo. Understanding what I was looking at took more work.
The package includes a visualization of the grid using a Flask WSGI frontend that you can easily view with your web browser. The graphics use Dash Cytoscape, a slick and powerful graph visualization engine that’s perfect for this sort of visualization.
While the picture was pretty, the informative data was presented on the console in the form of tables. Here are some examples:
| id | u_rated | node_type | feeder_branch_id | feeder_node_id | u | x_coor | y_coor |
|---|---|---|---|---|---|---|---|
| 1 | 10500.0 | 0 | 64 | 61 | 0.0 | 125.848.. | 245.522.. |
| 2 | 10500.0 | 0 | 65 | 61 | 0.0 | 385.322.. | 175.70.. |
| 61 | 10500.0 | 1 | -2147483648 | -2147483648 | 0.0 | 134.732.. | 145.515.. |
| id | from_node | to_node | from_status | to_status | feeder_branch_id | feeder_node_id | is_feeder | r1 | x1 | c1 | tan1 | i_n | i_from |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 63 | 61 | 12 | 1 | 1 | 63 | 61 | True | 0.411.. | 0.023.. | 0.0 | 0.0 | 110.013.. | 0.0 |
| 74 | 20 | 8 | 1 | 1 | 63 | 61 | False | 0.585.. | 0.000.. | 0.0 | 0.0 | 227.694.. | 0.0 |
| 125 | 96 | 94 | 1 | 1 | 63 | 61 | False | 0.036.. | 0.04.. | 0.0 | 0.0 | 362.904.. | 0.0 |
## Transformers
| id | from_node | to_node | from_status | to_status | feeder_branch_id | feeder_node_id | is_feeder | u1 | u2 | sn | tap_size | uk | pk | i0 | p0 | winding_from | winding_to | clock | tap_side | tap_pos | tap_min | tap_max | tap_nom |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 123 | 5 | 95 | 1 | 1 | 64 | 61 | False | 10500.0 | 3000.0 | 30000000.0 | 0.0 | 0.203 | 100000.0 | 0.0 | 0.0 | 0 | 0 | 12 | 0 | 0 | 0 | 0 | 0 |
| 124 | 12 | 96 | 1 | 1 | 63 | 61 | False | 10500.0 | 3000.0 | 30000000.0 | 0.0 | 0.203 | 100000.0 | 0.0 | 0.0 | 0 | 0 | 12 | 0 | 0 | 0 | 0 | 0 |
Setting up and running the code was trivial. Understanding the output and the implications of what the software does was not. My background is as a Linux Systems Admin and Python Programmer; I don’t have a background in electrical engineering.
I started by drilling into the data structures, functions, looking at the clear and concise API, and doing research.
I had always pictured the grid as a complicated but largely static circuit. What became clear is that it’s better understood as a dynamic physical system, where electrical properties like reactance and reactive power materially influence behavior in ways that aren’t immediately intuitive. The grid is similar to a living, breathing entity.
Right away, there was a value in the demo, reactance per kilometer, which also shows up as an attribute of the lines, x1. Reactance was probably the hardest part to wrap my mind around. I did end up watching some YouTube videos and talking it through with ChatGPT. Reactive power is central to understanding why the grid is so difficult to manage. A full explanation is beyond the scope of this post, but it’s an essential concept for appreciating the system’s behavior.
I didn’t drill into every attribute of the system; I was just trying to get a sense of what this package did and achieve an overview of how it mapped into the real world.
When I realized how complicated and intricate the grid actually was, the scale of it jumped a couple of orders of magnitude in my mind. As I mentioned earlier, my background includes Linux, and I’ve worked in Ops teams at places like CIBC, Merrill Lynch, Moneris Solutions, and SiGe Semiconductor. I’ve seen those big dashboards full of technical detail that provide the Ops Teams with a dashboard. Then I googled for a Hydro One (Ontario’s power producer) ops dashboard.
While this is only a slice of the system, it illustrates the density and complexity operators deal with in practice.
The pgm-ds software allows you to dynamically modify the grid, add and remove components and then it reports on faults and failures. It allows you to re-route power through redundant links and more. You can model changes and then try to forecast future demand and the effects of change.
With a system this complex, simulation becomes a natural foundation for machine learning. Tools like pgm-ds make it possible to generate structured scenarios for forecasting, anomaly detection, and decision support.
Extending and managing the grid is not only non-trivial, it’s also a slow moving project. Building a power plant, a dam, a data center, a factory, or a neighborhood all take time.
This field is both technically fascinating and materially important. Tools like this don’t just model infrastructure—they help shape how it evolves. That makes the work both intellectually engaging and meaningful.