Enable total capacity constraints#1417
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1417 +/- ##
==========================================
- Coverage 86.80% 86.79% -0.02%
==========================================
Files 59 59
Lines 8384 8375 -9
Branches 8384 8375 -9
==========================================
- Hits 7278 7269 -9
Misses 790 790
Partials 316 316 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
tsmbland
left a comment
tsmbland
left a comment
There was a problem hiding this comment.
Good start.
I've realised that my original plan wasn't as solid as I thought, so the actual implementation will be quite different. The input/validation code is nearly there though so I'd focus on tidying that up in this PR. If you put a note in the schema about the new parameter, mentioning that it's currently unused, then we could merge this and worry about the implementation later
| .get(&(self.region_id.clone(), self.commission_year)) | ||
| .and_then(|c| c.get_addition_limit().map(|l| l * commodity_portion)) | ||
| .and_then(|c| { | ||
| c.get_addition_limit(self.capacity()) |
There was a problem hiding this comment.
The capacity here isn't what we need in this context. This is the capacity of an individual candidate asset, which is the amount of capacity that we consider installing at a time (we may install multiple of these).
What we'd need to know is the total amount of capacity already installed, so we know how much wiggle room we have above this to install in the current year.
That said, this is more complicated than I originally thought. Because we decide how much of the existing capacity to keep (and how much to get rid of) as part of the investment process, which hasn't happened yet, we have a bit of a chicken and egg situation as we don't know how much capacity is installed (or, rather, how much of this will actually be kept).
Hope is not all lost, but this will require a different approach.
If you look at what happens currently with the addition limits, we store these in a map keyed by asset, and gradually trim from this as we install new capacity (i.e. coming from candidate assets). One way to implement the total capacity limit would be to have another map, keyed by process instead of asset, then gradually trim from this with all selected assets (both new assets and those chosen to be retained).
If this doesn't make any sense, or you don't want to worry about this, you can just focus this PR on the inputs/validation, but I'd remove the self.capacity() arg in any case as it's not right.
There was a problem hiding this comment.
I've removed this now, so get_addition_limit and ProcessInvestmentConstraint are as they were:
There was a problem hiding this comment.
More quick thoughts on implementing this:
select_best_assetscurrently takesinvestment_limits(containing the addition limits), which we use to cap the capacities of candidate assets (i.e. not-yet-commissioned assets), and gets whittled down every time a candidate is selected- The simplest approach to implement total capacity limits would be to take another map
HashMap<ProcessID, AssetCapacity>containing the total capacity limits. This would cap candidate assets in the same way as above, and also exclude any existing (non-candidate) assets with capacities higher than the current limit. (note that existing assets have fixed capacities so cannot have their capacities trimmed in the same way). This limit would get whittled down with every selected asset (candidate or existing). The initial limit would have to be scaled by the agent share, like we currently do for addition limits. Note that this should be keyed byProcessID, so you'll need to extract the process that each asset corresponds to. - Could be a nicer way to do this like passing
HashMap<ProcessID, ProcessInvestmentConstraint>. Would take a bit of creativity but I think it could work and probably cleaner than taking two separate maps.
tsmbland
left a comment
tsmbland
left a comment
There was a problem hiding this comment.
This is good! And a definite improvements to the tests.
The only think I might do is to mention the new parameter in the input file schema (schemas/input/process_investment_constraints.yaml), with a note that it's currently unused. I can see the argument for leaving it out though. In that case, I'd exclude it from muse1_default for now so we don't have undocumented parameters in the example models. Your call!
…it calculation" This reverts commit 0eebbb2. Defer to future, when all capacity constraints are implemented
62561ab to
e598605
Compare
|
@dc2917 Think this is ready shall I merge? |
Yes please! |
2 participants
Description
This PR enables the option to provide total capacity constraints.
total_capacity_limitcolumnIf found, the entries are parsed with a custom deserialiser, which handles emptytotal_capacity_limitentries and treats them as None.total_capacity_limitfield of theProcessInvestmentConstraintRawstruct.Noneare non-negative and finite.ProcessInvestmentConstraintnow has atotal_capacity_limitfield, for use inget_addition_limit(not yet implemented)get_addition_limitnow also takes anAsset's current capacity for use in the calculationexamples/muse1_default/process_investment_constraints.csvprocess_investment_constraints.csvinput files has been updated with details of this new columnFixes #1414
Type of change
Key checklist
$ cargo test$ cargo docpresent in the previous release
Further checks