num_units column in assets.csv

[tsmbland]

Description

This is the first step on the way to making all assets divisible (#1441). This PR makes all assets provided in assets.csv divisible (changing capacity from Continuous to Discrete). Since not all processes have a defined unit_size (and we want to keep this optional), we need an extra column (num_units) specifying how many units to split the capacity into. For processes with a defined unit_size, num_units takes precedence. If n_units is not specified, the behaviour is essentially equivalent to how it currently is: split processes with unit_size according to this, and processes without n_units remain non-divisible (i.e. discrete capacity with a single unit). For now, I've omitted this column from the example models, so the results are unchanged (Note: this does affect the output files, but only because it changes the num_units column in asset_capacities.csv. Total capacities, flows and prices should be unchanged). In the future, it would probably be worth changing this to make the example models more realistic.

Eventually I want to drop AssetCapacity::Continuous entirely, but it's currently also used by assets invested in by MUSE. This is the next thing to change (#1483)

This PR doesn't make much sense to merge without #1483, but I still figured I'd keep it separate to make it slightly easier to review (#1483 is pretty big so anything to break it up).

Fixes # (issue)

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
• Update release notes for the latest release if this PR adds a new feature or fixes a bug
  present in the previous release

Further checks

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

[Copilot]

Pull request overview

This PR introduces an explicit num_units field for user-provided assets to support making all assets.csv assets representable as discrete “units”, as an incremental step toward making all assets divisible (Issue #1441). It also standardises naming by renaming AssetCapacity::n_units() to AssetCapacity::num_units() and updates call sites accordingly.

Changes:

• Add optional num_units parsing from assets.csv and derive discrete AssetCapacity from either explicit num_units, process unit_size, or default to a single unit.
• Rename AssetCapacity::n_units() → AssetCapacity::num_units() and update usages in optimisation/output/asset logic.
• Update the input schema (schemas/input/assets.yaml) to document the new num_units column.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/simulation/optimisation.rs	Updates capacity constraint logic to use AssetCapacity::num_units().
src/output.rs	Outputs num_units via the renamed AssetCapacity::num_units() accessor.
src/input/asset.rs	Adds num_units CSV field and constructs discrete AssetCapacity for user assets based on num_units/unit_size.
src/asset/pool.rs	Updates tests/construction to pass explicit AssetCapacity for UserAsset::new.
src/asset/capacity.rs	Renames n_units() to num_units() and updates related tests.
src/asset.rs	Changes UserAsset::new to accept an explicit AssetCapacity and updates internal/tests accordingly.
schemas/input/assets.yaml	Documents the new optional num_units column for assets.csv.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codecov]

Codecov Report

❌ Patch coverage is 94.73684% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.02%. Comparing base (e13b1ad) to head (e1649d2).

Files with missing lines	Patch %	Lines
src/simulation/optimisation.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1480   +/-   ##
=======================================
  Coverage   90.02%   90.02%           
=======================================
  Files          60       60           
  Lines        8558     8562    +4     
  Branches     8558     8562    +4     
=======================================
+ Hits         7704     7708    +4     
  Misses        535      535           
  Partials      319      319           

☔ View full report in Codecov by Harness.
📢 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.

[dc2917]

Makes sense!

[dalonsoa]

The code looks OK, so approving, but I do not understand the use case. See my comment below.

[dalonsoa]

I'm not entirely sure about the purpose of this parameter, to be honest. If a process has unit_size, the number of units can be calculated out of it, as described. And if not, the number of units is one, also as described. So, why giving the option of indicating the number of units manually? It seems like adding another way of confusing the user.

[tsmbland]

Agree it's confusing but it's what Adam wants. Two reasons:

• For processes with a defined unit_size, relying on unit_size here requires capacities to be an exact multiple of unit_size, otherwise the data is incoherent (capacities will be rounded up so that everything works, but this fundamentally changes the system so should be avoided). Defining num_units here allows the data to be coherent without changing overall capacities
• For processes without a defined unit_size, num_units=1 is just a default (which we may remove in the future). Specifying num_units allows these assets to be "divisible", in the sense that they do not have to be decommissioned in one go (which was not possible before)

Perhaps will make more sense in the context of #1483, which also clarifies the documentation a bit.

[dalonsoa]

OK, I see the second point. But the first one feels a bit dodgy.

Let's take the usual example of wind turbines. You have that each turbine has 10 kW of capacity (a defined process with specific costs, etc). A user might ask for 45 kW of capacity, which means 5 turbines - and hence an actual capacity of 50 kW. If the user then says I want 9 units because of reasons, that results in a unit size of 5 kW, which is not what the process represents. I feel this is way less realistic that rounding up to the closest whole number of units...

[tsmbland]

I don't disagree, but at least now we're giving the user a choice between two imperfect solutions 🤷