Recent searches
Search options
Administered by:
@jack@social.jacklinke.comWithout formal training, the way I modeled physical distribution system #Infrastructure for utilities districts in my #Django app evolved significantly over time.
As I learned more about graph theory and simulation, I figured out how to model for both the physical structure and the logical aspects of their interconnection and behavior in various scenarios.
#GraphTheory #WaterInfrastructure #Modeling
1/6
Past decisions made with limited knowledge can come back to bite... hard.
I finally formalized "Model 1" last year. It's a detailed, fully-documented internal standard for modeling infra in #Django for water accounting, scheduling, simulation, and more. It’s not perfect, but it meets my needs and looks beautiful visualized, IMO.
2/6
Side note: I usually use MermaidJS for graph topology vis, but for large graphs, it wasn’t cutting it.
For this project, I’m using cytoscape.js-dagre – it's been quite nice (though library development seems to have slowed, and it sometimes pushes nodes too far apart, but it handles the graph’s complexity much better)
https://github.com/cytoscape/cytoscape.js-dagre/
3/6
Now that I have my new standard, I’m revisiting past districts to update them.
Preparing to implement these changes in the production database without disruption is the most mentally taxing thing I've worked on in some time.
Though at a smaller scale, it feels like one of those big engineering projects where they move an entire housing complex 5 blocks away while tenants are still inside. Same vibe.
4/6
The changes I’m making require significant restructuring of the graph model.
The average district's graph model has ~2,000 nodes and ~2,500 edges, but Model 1 requires more, along with significant restructuring to insert new nodes and edges representing concepts like diversions, connected meters, etc..
It’s not huge by graph standards, but these changes are complex and challenging.
5/6
I started by importing all nodes and edges into #NetworkX, incorporating changes step-by-step, and visualizing the graph at each stage to spot any anomalies.
Now, I’m translating from NetworkX operations to database operations to implement these changes in the production database via Django shell.
6/6
@jack excited to hear more about what you land on here.
@carlton Well, if nothing else, I have gotten really good at dropping & restoring messed up databases! 
I need to read more on transactions. Even though I wrapped the entire script I'm running in a transaction, it must be too much at once or something. It does not roll back to the original state the way I expected it to.
New approach will be to break the process into smaller, ordered chunks instead of trying to do all the processing in one fell swoop. Run one, verify, move on to the next.