Add circularity example #914
Conversation
|
@ahawkes I've added your second model with a bigger circularity Attaching the graph generated by MUSE to help visualise the model (with CO2 removed to simplify it a bit) 
There's another problem with this that OAGRSV has multiple SED outputs (GASPRD and OILCRD), and we have to select one of them as a primary output. Both of these commodities are owned by the same agent, which makes a lot of sense, however since agents consider each commodity one at a time, and only consider processes with that commodity as the primary output:
Just thought I'd mention since, even if we come up with a viable solution for loops, the big loop in this model will never be used, unless we rethink the whole "primary commodity" thing. Ideally I think we should allow agents to consider all of their commodities simultaneously, and consider any process that can produce any of these commodities. If we did that then OILCRD effectively becomes part of the loop as well (or, at least, needs to be considered alongside it) |
|
Thanks.
Yes I think that's a known issue with choosing a primary commodity - weird things may happen with the other SED outputs.
But isn't the 1st option here not that bad? Or at least consistent with the primary commodity assumption? We're assuming we don't care about the H2YPRD-GASPRD loop.
And isn't it a rule that for each SED/SVD commodity, there must be at least one process that has it as the primary output commodity? So GASPRD demand will still be considered for investment.
And the big loop in the model will be used, because there is OILCRD demand, which requires H2YPRD input, which in turn has implications for H2YPRD demand/capacity. So once one reaches the end of the first pass of investment appraisal, one needs to go back to H2YPRD and re-do investment to make sure there's enough capacity there?
…________________________________
From: Tom Bland ***@***.***>
Sent: 17 October 2025 13:54
To: EnergySystemsModellingLab/MUSE2 ***@***.***>
Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***>
Subject: Re: [EnergySystemsModellingLab/MUSE2] Add circularity example (PR #914)
[https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland left a comment (EnergySystemsModellingLab/MUSE2#914)<#914 (comment)>
@ahawkes<https://github.com/ahawkes> I've added your second model with a bigger circularity
Attaching the graph generated by MUSE to help visualise the model (with CO2 removed to simplify it a bit)
graphviz.8.png (view on web)<https://github.com/user-attachments/assets/831575a0-8491-4f34-aefe-850ed7d3dd13>
There's another problem with this that OAGRSV has multiple SED outputs (GASPRD and OILCRD), and we have to select one of them as a primary output. Both of these commodities are owned by the same agent, which makes a lot of sense, however since agents consider each commodity one at a time, and only consider processes with that commodity as the primary output:
* If we choose OILCRD as the primary output, then this process won't be considered to meet GASPRD demands, so the H2YPRD->GASPRD loop connection will never be used
* If we choose GASPRD as the primary output, then there will be no processes available for OILCRD investment, and the simulation will fail.
Just thought I'd mention since, even if we come up with a viable solution for loops, the big loop in this model will never be used, unless we rethink the whole "primary commodity" thing.
Ideally I think we should allow agents to consider all of their commodities simultaneously, and consider any process that can produce any of these commodities. If we did that then OILCRD effectively becomes part of the loop as well (or, at least, needs to be considered alongside it)
—
Reply to this email directly, view it on GitHub<#914 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLKGSSU4DLGNZOABQ2D3YDRGXAVCNFSM6AAAAACJBGN52WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMJVGQ4DKNZRHA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Is there a way to do something like a topological sort that produces something useable when there are circularities? - e.g. a commodity order that would minimise the need for iteration across commodities. Or anything useful - I'm sure someone somewhere has had similar problems at some point.... Possible broad approach (which no doubt has many complications):
|
Yes, we can identify strongly connected components, compress them into a single "group node" and then do a topological sort. You'd get something like this: 
(Note there are many valid topological sorts, this is just one of them) You could then run through the nodes in order, as we currently do, then when you get to a group node you could run an ironing out loop within that group (in this case I don't think it matters what order we solve the commodities in). If we're not converging on commodity prices then I don't think we have to run an ironing-out loop over the whole system, just within the group(s) of strongly-connected commodities. Two common scenarios I can imagine:
We'll obviously have a limit on how many times we can iterate, but ultimately we'll probably have to accept some amount of unmet demand somewhere.
Yeah there's no problem, I'm just saying that the loop is kind of irrelevant in this example so perhaps not very useful for development
Kind of. But if this H2YPRD requires extra GASPRD, then this won't be met by OILCRD as this isn't a primary producer of GASPRD. Apart from the H2YPRO/H2YGEN loop, all of the H2YPRD demand is known upfront once we've solved OILCRD. I've tried to clarify this by using dashed lines for non-primary flows in the above graph. Really, if we're sticking to the current primary commodity approach, then we only need to consider primary outputs when determining the investment order, which would give us something like this: 
So no big loop when it comes to investments, just a small one |
|
We'll also have to be careful that loops can't "create energy out of nowhere", otherwise I could very well imagine a self-reinforcing loop that meets the full commodity demands without any inputs |
|
OK - yes - can you think of an example model that has a better big loop? The supernode thing could be interesting for this. Also there appears to be methods to approximate the minimum feedback arc set - essentially trying to find the order that requires the minimum number of edges to be cut to remove all cycles from the graph. petgraph does not appear to have a method for this, but Gemini (so should not be trusted!) says:
This algorithm attempts to place nodes that are part of a cycle close to each other. The edges that go "backward" in this final ordering are the feedback arc set. It's not guaranteed to be the absolute minimum feedback arc set, but could be a good approximation and apparently is computationally very fast. |
|
I think we should try the topological sort using the supernode thing. The next question is how to deal with investment within each supernode. I'm not sure how much it matters other than that the pure internal nodes (i.e. that are not entry points to the supernode) probably should not be first for investment? Other than that, maybe start with the one with the greatest commodity demand that comes from outside the supernode? Also I was reading on various graph theory measures of connectedness (betweenness centrality, closeness centrality, and degree centrality), but not clear to me how much these might matter. Any thoughts @tsmbland ? Overall we want the best chance of fast convergence (both within and between supernodes). Maybe could even give the user options in the setup file - investment prioritisation based on betweenness centrality, closeness centrality, degree centrality, and maximum entry demand, etc etc? |
👍
If we're happy to let it keep iterating until it converges, then I don't think the order matters. But yes, to help it converge quickly, or if we're inevitably going to have to trade off convergence/unmet demand, then it will require more thought. Definitely makes sense to solve entry nodes before internal nodes. Beyond that I'm not really sure. First guess I'd probably rank based on minimum distance to an entry node, but there may be more sophisticated things we can do. Obviously becomes more of an issue the larger the cycle is. I think it will require some experimenting |
|
Additional thought:
Would require changes to docs too of course! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #914 +/- ##
=======================================
Coverage 83.95% 83.95%
=======================================
Files 50 50
Lines 5696 5696
Branches 5696 5696
=======================================
Hits 4782 4782
Misses 685 685
Partials 229 229 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Not for merging. I'm just keeping this open as a draft PR so we have something to work with during while we try to add support for circular commodity flows
Temporarily turned off graph validation so it can get to the dispatch run in the first year. It will panic after this when it gets to investment