We currently have "divisible" assets, which are composed of one or more units with a defined capacity (based on the unit_size input parameter), and "non-divisible" assets, which have a single capacity. The main behavioural effect of this is that "divisible" assets can be partially decommissioned, in the sense that retention decisions are made for each unit (so, for example, an asset composed of 100 units could decide to decommission 20 of them in 2030 and a further 30 of them in 2035), whereas "non-divisible" assets must be decommissioned entirely in one go.
The proposal, based on a conversation with @ahawkes on Teams, is that all assets should behave like the current "divisible" assets, but should come in two flavours:
- Assets from processes with a defined
unit_size. These should behave similarly to existing "divisible" assets
- Assets from processes without a defined
unit_size. In this case the unit size should be determined dynamically based on demand each year when investment decisions are made. This should be what's currently referred to as the "trial capacity" in the investment documentation, which is based on the capacity_limit_factor.
Asset investment/retention and dispatch would then be consistent for all assets, the only exception being how the unit size is calculated (hardcoded or dynamic):
- assets are invested in one unit at a time
- assets are re-appraised one unit at a time
- units from the same parent asset are grouped together in dispatch
- all user-facing (non debug) output files should just refer to ids of groups. For debug files we may still need a way to distinguish between units from the same group
Some nuances:
- In the final investment round we currently cap capacities for "non-divisible" assets based on demand-limiting-capacity and process investment constraints. For example, if the "trial capacity" is 5 and the demand limiting capacity is 2, then we'd appraise a capacity of 2. This prevents investing in capacity that isn't needed. For assets with a defined
unit_size, we'd still appraise the full unit (since unit_size is strictly enforced), except when that would violate process investment constraints, in which case we'd drop from appraisal. In the new approach, we have a choice:
- Strictly enforce unit sizes (whether set by
unit_size or dynamically), in which case we'd follow the approach we currently follow for divisible assets
- Allow capacity of the final unit to be capped by demand limiting capacity. Since asset capacities are represented by
n * unit_size, we'd either have to represent this capacity as an additional stub asset (1 * unit_size_capped), or scale unit_size accordingly so that n * unit_size still matches the total capacity.
- What to do about assets in the
assets.csv input? These will need to be split into units, but we'll need an extra parameter (n_units) to say how many units to split them into. For assets with a defined unit_size, we could disallow n_units and calculate it as we currently do (ceil(capacity / unit_size)), but Adam's not mad about this approach as it changes total capacities, so alternatively we could allow n_units to be specified, in which case unit_size would be overwritten for these assets.
We currently have "divisible" assets, which are composed of one or more units with a defined capacity (based on the
unit_sizeinput parameter), and "non-divisible" assets, which have a single capacity. The main behavioural effect of this is that "divisible" assets can be partially decommissioned, in the sense that retention decisions are made for each unit (so, for example, an asset composed of 100 units could decide to decommission 20 of them in 2030 and a further 30 of them in 2035), whereas "non-divisible" assets must be decommissioned entirely in one go.The proposal, based on a conversation with @ahawkes on Teams, is that all assets should behave like the current "divisible" assets, but should come in two flavours:
unit_size. These should behave similarly to existing "divisible" assetsunit_size. In this case the unit size should be determined dynamically based on demand each year when investment decisions are made. This should be what's currently referred to as the "trial capacity" in the investment documentation, which is based on thecapacity_limit_factor.Asset investment/retention and dispatch would then be consistent for all assets, the only exception being how the unit size is calculated (hardcoded or dynamic):
Some nuances:
unit_size, we'd still appraise the full unit (sinceunit_sizeis strictly enforced), except when that would violate process investment constraints, in which case we'd drop from appraisal. In the new approach, we have a choice:unit_sizeor dynamically), in which case we'd follow the approach we currently follow for divisible assetsn * unit_size, we'd either have to represent this capacity as an additional stub asset (1 * unit_size_capped), or scaleunit_sizeaccordingly so thatn * unit_sizestill matches the total capacity.assets.csvinput? These will need to be split into units, but we'll need an extra parameter (n_units) to say how many units to split them into. For assets with a definedunit_size, we could disallown_unitsand calculate it as we currently do (ceil(capacity / unit_size)), but Adam's not mad about this approach as it changes total capacities, so alternatively we could allown_unitsto be specified, in which caseunit_sizewould be overwritten for these assets.