New tranching approach#1395
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1395 +/- ##
==========================================
- Coverage 89.45% 86.80% -2.66%
==========================================
Files 59 59
Lines 8377 8384 +7
Branches 8377 8384 +7
==========================================
- Hits 7494 7278 -216
- Misses 562 790 +228
+ Partials 321 316 -5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
tsmbland
force-pushed
the
second_new_tranching_approach
branch
from
ce1fad6 to
4af71c6
Compare
There was a problem hiding this comment.
Pull request overview
Implements a revised tranching approach for candidate asset sizing in the investment loop by assigning candidate capacities from an annual-demand-based characteristic capacity scale, then applying capacity_limit_factor as the per-round appraisal fraction.
Changes:
- Add an annual-demand-based capacity scaling helper and use it to size candidate assets during option generation.
- Adjust the default
capacity_limit_factor(0.1 → 0.05) to reflect the new capacity scaling behaviour. - Update the model schema documentation for
capacity_limit_factorto describe the new meaning.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/simulation/investment.rs | Introduces annual-demand-based candidate capacity scaling and adds tests around the new helper. |
| src/model/parameters.rs | Changes the default value of capacity_limit_factor to align with the new tranching increments. |
| schemas/input/model.yaml | Updates schema docs/default for capacity_limit_factor to match the new candidate sizing approach. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Default values for optional parameters | ||
| allow_dangerous_options: false, | ||
| candidate_asset_capacity: Capacity(1e-4), | ||
| capacity_limit_factor: Dimensionless(0.1), | ||
| capacity_limit_factor: Dimensionless(0.05), | ||
| value_of_lost_load: MoneyPerFlow(1e9), |
There was a problem hiding this comment.
There will be more to add to the release notes. Best to do this just before making a release, as we've done in the past.
dalonsoa
left a comment
dalonsoa
left a comment
There was a problem hiding this comment.
This looks good to me, but I'm lacking a bit of the current context - in addition to getting up to speed with the Discrete/Continuous AssetCapacity, which is new for me:
- Has what is mentioned in #1358 as
capacity_granuarityended up beingcapacity_limit_factor? - In both cases (Discrete/Continuous) you are appraising an asset that can cover a portion of the demand. In the Discrete case, this portion is fixed by the user (
unit_size, 1 unit), while in the Continuous case, this portion is calculated dynamically based on the annual demand to be covered, right? - Are these portions used for appraisal otherwise known as trenches?
|
|
||
| /// Calculates a characteristic capacity scale for a candidate asset. | ||
| /// | ||
| /// The returned value is the capacity that would satisfy the total annual demand assuming the asset |
There was a problem hiding this comment.
By total annual demand you mean if this were the only asset available and it had to satisfy it entirely, right?
tsmbland
left a comment
tsmbland
left a comment
There was a problem hiding this comment.
This looks good to me, but I'm lacking a bit of the current context - in addition to getting up to speed with the Discrete/Continuous
AssetCapacity, which is new for me:
- Has what is mentioned in #1358 as
capacity_granuarityended up beingcapacity_limit_factor?
They're two alternative approaches that Adam suggested trying, before setting on this one. capacity_granuarity was just a fixed pre-defined capacity. capacity_limit_factor already exists on main and is broadly similar to what it was before, except that it's being multiplied by something else.
- In both cases (Discrete/Continuous) you are appraising an asset that can cover a portion of the demand. In the Discrete case, this portion is fixed by the user (
unit_size, 1 unit), while in the Continuous case, this portion is calculated dynamically based on the annual demand to be covered, right?
Yes
- Are these portions used for appraisal otherwise known as trenches?
tranches, although I might suggest dropping that terminology as it's a bit confusing.
I'm working on some documentation (#1416) which will hopefully make this all clearer.
|
|
||
| /// Calculates a characteristic capacity scale for a candidate asset. | ||
| /// | ||
| /// The returned value is the capacity that would satisfy the total annual demand assuming the asset |
Description
Implements the second tranching idea discussed in #1358 (at the bottom), which uses a dynamic capacity approach, where candidate asset capacities are set according to annual demand:
capacity = capacity_limit_factor * annual_demand / max_annual_supply_per_capacityThis is similar to the current demand-limiting-capacity approach, but slightly safer as it cannot be throw off by extreme demand/availability values in any particular timeslices.
Also changing
capacity_limit_factorto 0.05, as suggested by Adam, but we may change this after more testingBased on a discussion with Adam on teams, we've decided that divisible assets should be appraised one unit at a time.
I've had to turn off tests for
circularityandcircularity_npvas these are failing. We have an issue open for this (#1368).Fixes #1358
Type of change
Key checklist
$ cargo test$ cargo docpresent in the previous release
Further checks