"full"/"full_average" prices can be elevated by under-utilised capacity
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 42/100
Research direction
No files or tests are named; start by locating the full and full_average price calculations and reproduce the first-year case with under-utilised user-defined capacity. Compare the capital/fixed-cost handling with the MUSE1 approach described here, then define expected pricing or warning behavior before adding coverage.
Written by the indexing model from the issue text.
Description
If assets are under-utilised, the capital cost per unit output can be very high, which elevates prices calculated using the "full"/"full_average" methods.
In later years of simulations, where assets are invested in to meet demands, and unused assets can be decommissioned early (or partially decommissioned), this may not be such a problem as capacities will generally not exist unless utilised.
However, in the first year, we don't do any commissioning/decommissioning and calculate prices based on dispatch of assets defined in the user data. If users have set capacities higher than they need to be, resulting in under-utilised capacity, then prices in the first year may be extremely high as a result of this. To some extent it's down to the user to pick suitable capacities, but that does seem a little harsh given that users won't know how assets will end up being utilised, and since there's no warning about this they'll probably end up confused by the high prices.
Not sure what the best solution is here. We were faced with this problem in MUSE1 and decided to calculate capital/fixed costs based on the capacity that's actually utilised, rather than the total capacity that exists (although in that case we didn't have the saving grace of early decommissioning so that was really the only solution). In MUSE2, I think early decommissioning (and especially partial decommissioning) helps a lot, although that won't always happen and obviously doesn't help with the first year.
- Dominant language
- Rust
- Stars
- 8
- Forks
- 5
- Avg merge
- 11h 31m
- Merged PRs (30d)
- 33
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from EnergySystemsModellingLab/MUSE2
-
bug documentation
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
EnergySystemsModellingLab/MUSE2#1367 · 1 comment ·
-
Remove the `ironing out iteration 0` prefix from debug files when the ironing out loop is turned off Openmuse xiii question
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
EnergySystemsModellingLab/MUSE2#1221 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
EnergySystemsModellingLab/MUSE2#1554 ·
-
bug
EnergySystemsModellingLab/MUSE2#1541 · 2 comments · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
EnergySystemsModellingLab/MUSE2#1526 ·
All issues in EnergySystemsModellingLab/MUSE2
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
bug core
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW Openfuzz
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ClickHouse/ClickHouse#122114 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
linebender/vello_svg#90 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100