Skip to content

📝 Add process producing two outputs.#806

Closed
dalonsoa wants to merge 2 commits intomainfrom
756_processes
Closed

📝 Add process producing two outputs.#806
dalonsoa wants to merge 2 commits intomainfrom
756_processes

Conversation

@dalonsoa
Copy link
Copy Markdown
Collaborator

@dalonsoa dalonsoa commented Sep 4, 2025

Description

Adds an example with a process that produces two useful commodities. This is an hypothetical e-refinery that produces gas as well as electricity (maybe by making the gas pass through a turbine while it gets out of the depths of the Earth). The example uses as staring point the muse1_simple example, adding the relevant entries to the process related files.

As far as I can tell, despite being cheaper than the gassupply1, the e-refinery is never used and it makes no difference to the result. New capacity is added to the gassupply1 as time goes by, but nothing is added to the new tech. As far as I can tell, this makes no sense.

I notice that in neither the muse1_simple example nor the two that derive from it (two_regions and this one, two_processes - although it should be two_outputs) there is an investment in any technology that were not there at the start. New techs (windturbine, heatpump, gasCCGT or e-refinery) are never invested in, which point to a bigger problem.

Fixes #756

Type of change

  • Bug fix (non-breaking change to fix an issue)
  • New feature (non-breaking change to add functionality)
  • Refactoring (non-breaking, non-functional change to improve maintainability)
  • Optimization (non-breaking change to speed up the code)
  • Breaking change (whatever its nature)
  • Documentation (improve or add documentation)

Key checklist

  • All tests pass: $ cargo test
  • The documentation builds and looks OK: $ cargo doc

Further checks

  • Code is commented, particularly in hard-to-understand areas
  • Tests added that prove fix is effective or that feature works

@codecov
Copy link
Copy Markdown

codecov bot commented Sep 4, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.65%. Comparing base (a828721) to head (5d14885).
⚠️ Report is 296 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #806   +/-   ##
=======================================
  Coverage   86.65%   86.65%           
=======================================
  Files          46       46           
  Lines        5080     5080           
  Branches     5080     5080           
=======================================
  Hits         4402     4402           
  Misses        470      470           
  Partials      208      208           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@dalonsoa
Copy link
Copy Markdown
Collaborator Author

dalonsoa commented Sep 4, 2025

@tsmbland , @alexdewar it would be good it you could have a look at this. Not so much what I've implemented but my comment in the PR description. I think we have an issue with the solver.

@alexdewar
Copy link
Copy Markdown
Collaborator

@dalonsoa The reason MUSE2 is selecting gassupply1 over e-refinery is because they are both free and gassupply1 just happens to be the first considered because it's listed first in processes.csv.

I tried reordering processes.csv to induce MUSE2 to select the e-refinery instead, but then I got an error message about the model being infeasible, which isn't really ideal. I need to dig into it a bit more, but it seems like e-refinery shouldn't actually be being selected, even if we try to make MUSE2 do that, because it doesn't actually satisfy the constraints in some way. The plot thickens.

@dalonsoa
Copy link
Copy Markdown
Collaborator Author

I guess it is producing electricity when is not needed, so if the constrain is that supply == demand, things do break.

@alexdewar
Copy link
Copy Markdown
Collaborator

Ohhh good point. If I relax the commodity balance constraint so that supply is >= demand instead, then it works. I'm just not sure if there will be other consequences to doing that...

What do you think @ahawkes? The problem we have is that we have a process which produces both gas and electricity, but the model fails because it's producing electricity when we're investing for gas, so the electricity produced is all surplus to requirements because demand is zero for this dispatch run.

@ahawkes
Copy link
Copy Markdown
Contributor

ahawkes commented Sep 10, 2025 via email

@dalonsoa
Copy link
Copy Markdown
Collaborator Author

Maybe, for this example to make sense and be useful we need some process that needs electricity, so investing in the e-refinery makes more sense. We have heatpumps available, but they don't seem to be adopted by the algorithm - even in the default example, where the only option to use that is installing windturbines - so I'm not entirely sure if there's not anything off in the algorithm, anyway.

@alexdewar
Copy link
Copy Markdown
Collaborator

Maybe, for this example to make sense and be useful we need some process that needs electricity, so investing in the e-refinery makes more sense. We have heatpumps available, but they don't seem to be adopted by the algorithm - even in the default example, where the only option to use that is installing windturbines - so I'm not entirely sure if there's not anything off in the algorithm, anyway.

I think the algorithm is ok (famous last words). I'd just assume that heatpumps aren't seen as the economical choice for whatever reason.

Adding more demand for electricity won't actually make it more likely that the e-refineries will be selected at any stage of investment. It's a bit weird, but the reason is because the primary output for them is gas and so e-refineries won't be considered when investing for electricity (other outputs aren't counted).

For e-refinery to beat out gassupply1 it needs to be cheaper, but that's not possible while it's free. Tbh I'm not sure why gassupply1 is free in any of the models, actually! My first thought was that maybe it just represented the availability of natural gas or something (i.e. before any processing) so wasn't a "real" process, but that doesn't seem to be right, as it's an input to gasCCGT, for example (and I'm pretty sure power plants have to pay for their gas...). I've double-checked and the default model in MUSE1 has this property too, so it wasn't a mistake when @tsmbland ported it to MUSE2. Do you know @ahawkes?

Anyway, regardless of what we do for the other models, maybe you could just give both e-refinery and gassupply1 nonzero costs for now, with e-refinery being cheaper...?

We'll also need to do #822 before you'll be able to make progress on this issue, because I can't see a way to make this work while supply is constrained to be the same as demand.

@dalonsoa
Copy link
Copy Markdown
Collaborator Author

No longer relevant, as #903 covers the same functionality.

@dalonsoa dalonsoa closed this Oct 20, 2025
@dalonsoa dalonsoa deleted the 756_processes branch November 24, 2025 09:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A process that has more than one commodity output

3 participants