My initial goal was simple: I just wanted to link these constraint names to the physical lines on the map so I could feed the geometry into Gridraven Claw and start monitoring them. But you know how it goes—I wanted to see how far I could push the model, so I kept adding layer after layer of complexity.
One thing led to another, and I accidentally created a preliminary grid model for the entire ERCOT interconnection.
The problem is that OpenStreetMap data for power grids is often… let’s say “creative”. Lines are broken, voltages are missing, and connections don't always touch. You cannot just use a standard routing engine.
So I built a custom system to solve it.
1) The Logic: I wrote a graph based "Crystal Growth" algorithm. It starts with one substation we know for sure, and then it looks at the neighbors in the grid topology. Like solving a massive Sudoku puzzle, it propagates outwards, locking in substations one by one.
2) The Physics: I wrote a custom "Gap Jumping" router. If the line data in OSM is broken (which happens a lot!), my script calculates the physics (voltage, distance, direction) and "jumps" the gap to stitch the line segments together.
Midway through debugging the algorithm (see the GIF of congested lines), I stopped and looked at the graph.
I realized I hadn't just found the locations of the constraints:
1) I had the substations.
2) I had the transmission lines connecting them.
3) I had the voltage levels.
At this point, it is just a matter of pulling the power plant locations from the EIA official registry and plugging them into the graph nodes. Suddenly, you aren't just looking at a map; you have the foundation for a power flow model.
It is definitely over-engineered for a weekend project. But you know how it is. You start by looking for a few congested lines, and you end up with an intial digital twin of the Texas grid on your laptop.
Next step? Maybe I finally put this all into a dashboard. Or verify the conductor ratings with some weather data. Let’s see.
