Remove PACs from code and documentation

[alexdewar]

Description

The concept of PACs is going away in the new model, so we don't need to worry about them anymore. Huzzah!

Remove them from the code and documentation. I've done my best to update doc comments etc. so that they still make sense, but mistakes might have crept in.

Closes #596.

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]

Codecov Report

Attention: Patch coverage is 93.93939% with 2 lines in your changes missing coverage. Please review.

Project coverage is 85.58%. Comparing base (0b52f84) to head (552d469).
Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
src/input/process/availability.rs	83.33%	0 Missing and 1 partial ⚠️
src/input/process/flow.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #614      +/-   ##
==========================================
+ Coverage   85.39%   85.58%   +0.18%     
==========================================
  Files          38       38              
  Lines        3410     3357      -53     
  Branches     3410     3357      -53     
==========================================
- Hits         2912     2873      -39     
+ Misses        305      295      -10     
+ Partials      193      189       -4     

☔ 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.

[Copilot]

Pull Request Overview

The PR removes all references to Primary Activity Commodities (PACs) across code, tests, schemas, and docs to align with the new model. Key changes include:

• Dropped is_pac fields, PAC-specific methods, and related validations.
• Updated documentation comments, input schemas, and glossary to eliminate PAC terminology.
• Simplified flow parsing and validation logic by removing PAC-centric sorting and checks.

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/simulation/optimisation/constraints.rs	Update capacity constraint docs to remove PAC terminology
src/process.rs	Remove is_pac fields, iter_pacs, and update docs
src/input/process/flow.rs	Remove PAC import, fields, sorting, validation, and tests
src/input/process/availability.rs	Update availability doc comments to remove PAC references
src/input/process.rs	Remove PAC flag in test fixtures
src/asset.rs	Update asset methods and docs to remove PAC mention
schemas/input/process_parameters.yaml	Remove PAC-specific titles from schema
schemas/input/process_flows.yaml	Remove PAC-related schema fields
docs/glossary.md	Eliminate PAC glossary entries

Comments suppressed due to low confidence (3)

src/input/process/flow.rs:151

• The error message uses braces {} with variable names but they won't be interpolated. Use a formatted string with positional {} placeholders and pass the variables, e.g., ensure!(cond, "Missing entry for process {} in {}/{}", process_id, region, year);.

ensure!(
    map.contains_key(&(region.clone(), *year)),
    "Missing entry for process {process_id} in {region}/{year}"
);

src/input/process/flow.rs:144

• [nitpick] The parameter map is ambiguous; consider renaming it to flows_map or process_flows for clarity.

fn validate_process_flows_map(process: &Process, map: &ProcessFlowsMap) -> Result<()> {

src/simulation/optimisation/constraints.rs:106

• [nitpick] The phrase "for assets" is unclear; consider changing it to "for each asset" or "of the asset" to clarify the comment.

/// For every asset at every time slice, the sum of the commodity flows for assets must not exceed

[tsmbland]

I'm going to approve, but I suspect a few things are not quite right.

In particular, now that PACs are gone, I've think we've fundamentally changed the definition of "activity". Whereas before, this was measured in absolute units of the PAC per year (e.g, PJ/year), I think now it represents quantities of the flow coefficients. So if flow coefficients are e.g. PJ/year, then activity is actually unitless.

I'm starting to think more and more that a formal units system, like I proposed in #481, is the only way to be truly robust about this. Otherwise I could well see us introducing silly errors that would be difficult/impossible to spot.

[tsmbland]

I think now that PACs are gone, this now an activity limit rather than an energy limit (i.e. needs to be multiplied by flow coefficients to get energy limits for each commodity)

[alexdewar]

True. I'll update this.

[alexdewar]

I'm going to approve, but I suspect a few things are not quite right.

In particular, now that PACs are gone, I've think we've fundamentally changed the definition of "activity". Whereas before, this was measured in absolute units of the PAC per year (e.g, PJ/year), I think now it represents quantities of the flow coefficients. So if flow coefficients are e.g. PJ/year, then activity is actually unitless.

Good point. I'm sure there are mistakes dotted around. Hopefully we'll catch some of them as we go along, but it's probably worth skimming the docs again before we make a release.

I'm starting to think more and more that a formal units system, like I proposed in #481, is the only way to be truly robust about this. Otherwise I could well see us introducing silly errors that would be difficult/impossible to spot.

I think this is v good idea. Hopefully some of this stuff will be clearer in our own minds by the end of the engagement, but even then I can see it would be easy to make a mistake. And it'll be even easier for someone new to the project/the MUSE model. The nice thing about using a language like Rust is that the unit types would be a zero-cost abstraction (i.e. the program would run just as fast as if you were just using raw f64s).

I did think that we could even go one step further and add runtime checks for commodity flows to check that we aren't mixing up flows for different commodities (e.g. when adding them). This wouldn't be zero-cost though (it would probably hammer performance), so we'd probably want to make it a compile-time option (e.g. just do it for debug builds).