Skip to content

Enhance discount_avg function to support resolution parameter#71

Merged
trulsf merged 3 commits intomainfrom
tf/discount
Oct 1, 2025
Merged

Enhance discount_avg function to support resolution parameter#71
trulsf merged 3 commits intomainfrom
tf/discount

Conversation

@trulsf
Copy link
Copy Markdown
Member

@trulsf trulsf commented Sep 29, 2025

Working with OpenEMPIRE code, there was a need to support additional discount calculations. I am not totally happy with using 0 as a default value for the resolution parameter to indicate a continuous calculation (I would prefer Inf, but that would mean having to convert from a float somewhere).

@trulsf trulsf requested review from JulStraus and hellemo September 29, 2025 14:27
Copy link
Copy Markdown
Collaborator

@JulStraus JulStraus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see the appeal in adding additional methods for the discounting. However, there are a few thinks which I am a bit confused about:

  1. We do not allow other resolutions compared to 1. In this situation it is a binary decision. Should we extend it to allow for also other resolutions? That is rather straight forward through adding it as keyword argument. If not, we can also just use a Bool instead of Int as input.
  2. It is unclear from the documentation/docstrings what keyword arguments are allowed for type. We should add that. As a user is normally utilizing the function objective_weight, it would be necessary to add it there as well and not only in discount.
  3. The test is testing that the old avg is smaller, but we do not have any tests showing that it is correctly calculated?

Generally speaking, I think we could also restructure the discounting within TimeStruct. It is currently not entirely clear what is allowed for which input, at least in my opinion. Whether that should be part of this PR or a separate is up to debate. I could take a look at it.

As an example, we do not allow for discounting on OperationalScenario or RepresentativePeriod while we do allow for OperationalPeriod even if it is just a fallback for the strategic period. This is at least in my opinion not entirely consistent as it should be possible to also utilize discounting then on the other types.

Comment thread src/discount.jl Outdated
Comment thread src/discount.jl Outdated
Comment thread test/runtests.jl Outdated
@trulsf
Copy link
Copy Markdown
Member Author

trulsf commented Sep 30, 2025

I did a bit of rewrite based on the comments and have (hopefully) improved the docs and tests a bit. I agree that the whole discounting could be up for a better design and further discussions. I suggest to move that to a separate PR, as I would like to make a release with support for the new yearly average discounting. If you would have a go of such a PR, you are more than welcome to have a go at it.

Copy link
Copy Markdown
Collaborator

@JulStraus JulStraus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it looks good right now. The restructuring removed actually one if loop :)

I will take a look at it regarding restructuring it today. So if you do not mind to wait 1 day for registering it, we can take it in the same new version.

@trulsf trulsf merged commit 6610125 into main Oct 1, 2025
6 checks passed
@trulsf trulsf deleted the tf/discount branch October 1, 2025 07:05
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

Successfully merging this pull request may close these issues.

2 participants