Account for remaining values in multi-period models

[jokochems]

• Subtract remaining values for investments expressing their value at the end of the optimization horizon.
• Limit fixed costs to actual optimization horizon.

[jokochems]

I'll update the tests shortly. Feel free to already have a glimspe into the implementation. In case I haven't been mistaken, it hasn't been too hard to implement.

[jokochems]

After checking back with @nailend, I'll revise the implementation and guess that it gets leaner through the changes we discussed bilaterally.

[jokochems]

@nailend Please have a look when time allows:

• As we discussed, I limited the (per year) annuities and (per year) fixed costs to the optimization horizon.
• This way, there is no (urgent) need to account for remaining values.

@p-snft
I see two ways to account for remaining values:

1. Assume that investment expenses are "locked in".
2. Account for changes in investment expenses over time - what you suggested.

In terms of implementation, I also see two ways:

• A. Limit to payments that happen within the optimization horizon.
• B. Consider all payments over the lifetime and subtract the outside of optimization horizon payments again.

Here is how I proceeded:

• Starting off, I wanted to go for approach 2.B. and tried to implement that.
• In the course of the discussion with @nailend, we found that approach A. would lead to cleaner code and processing (e.g. not having to account for outside horizon fixed costs as it was before).
• Thus, I went for approach 1.A. in the first place. The main reason is that it was easier to implement, compared to 2.A. Alongside, I also fixed some bugs of the previous implementation.

In principle, we could also go for approach 1.A., but there are some design questions:

• We would need to compare at the end of the optimization horizon and add/subtract the difference in value. I'd have a rough idea how to do that.
• Additionally, we would require the information of the investment expenses at the end of the last period, i.e. the beginning of the next upcoming one that we do not simulate. While in principle, this information could be passed, it might also be somewhat counter-intuitive and potentially error-prone that you have to provide p + 1 instead of p periods.

What do you think, @p-snft?

[jokochems]

@p-snft Adding to what I stated above, I gave it some thought:

• What I have included in this pull request and what was the main motivation is actually rather a bug fix to prevent the bias towards earlier investments in the optimization horizon.
• Considering the cost change over time when evaluating an actual remaining value, to me is rather a feature. Thus, I suggest to leave it out here and open a dedicated pull request for that. Does this make sense to you?

[p-snft]

@p-snft Adding to what I stated above, I gave it some thought:

What I have included in this pull request and what was the main motivation is actually rather a bug fix to prevent the bias towards earlier investments in the optimization horizon.

Considering the cost change over time when evaluating an actual remaining value, to me is rather a feature. Thus, I suggest to leave it out here and open a dedicated pull request for that. Does this make sense to you?

I agree. Actually, my suggestion was rather meant as a quick fix: Instead of calculating the remaining value at the end of the time horizon, it would just have been left to the user to give it. Maybe, it can be considered the sloppy version of 2A.

[jokochems]

@nailend could you please re-review? @p-snft Could you add your review as well or accept in case @nailend finds nothing more that needs to be changed?

FYI: The failing docs test seems to be due to a failing docs test for a zenodo link. I assume it to be a temporary server problem for zenodo. [EDIT] They just migrated and announced that they are still working on slowness issues. I guess, the server timeout limit was just too harsh.

Thank you!

[jokochems]

@nailend and @p-snft: I added additional functionality, namely allowing to re-evaluate assets at the end of the optimization horizon as an (optional) feature, as @p-snft suggested in the issue. Please have a look at this as well. Thank you!

[p-snft]

I am just wondering if it is possible to move the economic calculations to https://github.com/oemof/oemof-tools/blob/dev/src/oemof/tools/economics.py. (That might be another PR, though.)

[jokochems]

I am just wondering if it is possible to move the economic calculations to https://github.com/oemof/oemof-tools/blob/dev/src/oemof/tools/economics.py. (That might be another PR, though.)

Sounds like a good idea, indeed for a future PR.

[nailend]

I think it's great! Thanks a lot for all the changes and improvements, this is of great help to us!

[p-snft]

I checked for code style and if it breaks "stable" functionality. I see no real issues with that regard. There is no reason I see against the merge, I only have small remarks.

[p-snft]

I am wondering whether we should re-introduce this for single-period models.

[jokochems]

That has been a discussion in a very old issue #556. I generally like the idea as well, but did not do so, because my intention was to add functionality, not to take major design choices for the existing framework.

[pep8speaks]

Hello @jokochems! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2023-10-20 08:32:53 UTC

[jokochems]

Thanks a lot for your reviews, suggestions and approvals, @nailend and @p-snft. I will merge this back.