Calculate expected decommission year for existing assets
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Domain
- data
Research direction
No files, tests, or entry points are named. Start by reading the context in issue #916 and locating the existing asset lifetime or decommissioning model; done should include a defined expected-year calculation for existing assets and a clear decision on the default and optional lifetime-variation setting.
Written by the indexing model from the issue text.
Description
I guess the idea is that for an asset type with average lifetime $<\tau>$, the probability that the actual lifetime, $\tau$ might be roughly distributed:
p(\tau) = \frac{1}{\sqrt{2\pi\sigma}}\exp\left\{-\frac{(\tau-<\tau>)^2}{2\sigma^2}\right\}(supposing that it is normally distributed as a simple go-to example).
When MUSE gets given a bunch of assets at the base year $t_0$, each with comissioning year $t_\mathrm{c}$, it could then calculate the expected decomissioning year $t_\mathrm{d}$, for each asset from that information and the probability distribution:
t_\mathrm{d} = t_\mathrm{c} + \frac{ \int_{t_0-t_\mathrm{c}}^\infty \tau p(\tau) }{ \int_{t_0-t_\mathrm{c}}^\infty p(\tau) }To get this working we can just set $\sigma=0.2\tau$, or similar, as a working default value and then make it an optional user setting later once it's working reliably.
The integral could obviously be tabulated and stored so that it is just look up function $t_\mathrm{d} = f(t_\mathrm{c},\tau)$ that gets called for each asset. These days though, and given the relatively small number of assets (<100) it'd probably be very quick even if calculated per asset.
What do you think is the best way to proceed?
Originally posted by @martinstringer in #916
- 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
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rocky-data/rocky#2181 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Openbot:ai-assisted component:indexer QA-roadmap status:untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
midnightntwrk/midnight-indexer#1557 ·