Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Capacity growth and total capacity constraints

Open
#1,398 6 comments 0 reactions 2 assignees View on GitHub

@AdrianDAlessandro is already working on this.

Since Aug 20, 2026.

Assessment

This issue has not been assessed yet.

Description

In MUSE1, users can provide three constraints on investments

  • addition limits: amount of added capacity in a year
  • growth limits: percentage change in capacity per year (e.g 0.1 -> max 10% growth allowed)
  • total capacity limits: a hard upper limit on total capacity

See MUSE1 docs here: https://muse-os.readthedocs.io/en/latest/inputs/technodata.html (under "Capacity constraints"). That goes through it in way more detail, with examples.

In MUSE2, we currently have addition constraints implemented, but not the other two. We need to find a way to get the other two constraints in there. Rough idea:

  • add two more columns to process_investment_constraints.csv
  • sensible validation (e.g. not negative)
  • missing values should be allowed -> implies no limit (just like MUSE1)
  • store these as extra fields in ProcessInvestmentConstraint. Note that growth limits will need to be pre-scaled at load time based on the gap between milestone years, just like we currently do for addition limits.
  • modify get_addition_limit to solve all the maths to get an overall addition limit, taking into account the three different constraints
  • This addition limit can then be used downstream just as it currently is (i.e. scaled by the commodity_portion*, returned from max_installable_capacity, etc.)

The main challenge is that calculating an overall addition limit from the provided growth limits and total capacity limits requires knowledge of the current capacity, so we'll need to find a way to make max_installable_capacity and get_addition_limit aware of this.

Quite a lot to do, so may be best to break this into multiple PRs (e.g. one for input loading and validation, one for implementation)

* It may actually be more correct to gather the capacity owned by each agent first, and calculate growth limits from this, rather than summing all capacity, calculating an overall limit, then splitting this between agents according to their commodity portion. That would probably require more substantial changes to the code, but could be considered as a future improvement.

Dominant language
Rust
Stars
8
Forks
5
Avg merge
11h 31m
Merged PRs (30d)
33

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EnergySystemsModellingLab/MUSE2

All issues in EnergySystemsModellingLab/MUSE2

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.