Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harmonise optimisation for upfront invest and multi-period invest #1107

Open
3 tasks
p-snft opened this issue Aug 19, 2024 · 1 comment
Open
3 tasks

Harmonise optimisation for upfront invest and multi-period invest #1107

p-snft opened this issue Aug 19, 2024 · 1 comment
Milestone

Comments

@p-snft
Copy link
Member

p-snft commented Aug 19, 2024

Currently, there are different code paths for upfront invest and multi-period invest, we should make upfront invest a special case of the multi-period invest, where only one investment period exists. To do so, there are several steps:

@p-snft p-snft added this to the next major ({N+1}.0) milestone Aug 19, 2024
@p-snft
Copy link
Member Author

p-snft commented Sep 3, 2024

Some thoughts about this (partly from discussion with @jokochems):

  • VDI2067 lists capital-related costs, demand-related costs, and operation-related costs (plus other costs).
  • In solph, the ep_costs of an investment translate to the capital-related costs. The other costs are not so easy to distinguish: Both demand-related costs and operation-related costs can be attributed to flows (or, esp. storage content).
    1. Still, to keep at least the CAPEX distinct, it might make sense having "fixed costs" as operation-related costs that cannot be avoided once an investment has been made.
    2. We could drop the fixed costs (again) an just have energy-related costs (€/kWh/a) and capacity related costs (€/kW/a).
  • The current multi-period optimisation allows to have gaps between the displayed periods, but does not care about transitions. This particularly means that e.g. a battery storage might be emptied in the end of 2020 as recharging is cheap in 2030 (the next period). There are ways to tackle this, but for the moment I'd just assume continuous time.
  • As the TIMESTEPS and TIMEPOINTS are unique, it is possible to completely drop the period index and instead map from the main index to the period.
    1. The mapping might happen globally (global periods), similar to the way it is done right now.
    2. Or every investment can get a point in time as a local parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant