-
Notifications
You must be signed in to change notification settings - Fork 8
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
Tidy up the use of interpolation #642
Conversation
34d875b
to
02d5b4b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've a question, but the changes make total sense to me. Performance wise, it might even be faster as, presumably, a lookup of the value(s) will be faster than interpolating. In any case, it is more explicit, for sure.
@@ -437,6 +402,25 @@ def avoid_repetitions(data: xr.DataArray, dim: str = "year") -> xr.DataArray: | |||
return data.year[years] | |||
|
|||
|
|||
def interpolate_capacity( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conceptually, I'm not entirely sure if a linear interpolation of the capacity makes much sense. Capacity should only change when there's an investment in the relevant technology, so it should look very much staircase, going up only in the investment years. Wouldn't previous
make more sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're completely right, yes. If the capacity profile was created with cliff_retirement_profile
, which I believe most are, then there will be no difference, but in general forward filling makes more sense than linear interpolation.
I've created an issue about this (#656) and will return to it later. It's an easy change to make, but some of the results are affected and I'd like to understand why before merging.
d915405
to
d08e454
Compare
f013954
to
ee77e7e
Compare
Description
I've always been a bit bugged by the over-reliance on temporal interpolation. After all, there's a well defined time framework, which most objects should follow, so interpolation should rarely be required. Yet the code is riddled with unnecessary uses of
interp
.I've found that most of these
interp
calls can be changed tosel
without problem (in the case that the objects in question do cover the appropriate years), whereas others uses ofinterp
are still necessary (i.e. where the object doesn't cover the appropriate years).I think it's far better to be explicit about this, as using
interp
where it's not necessary could hide genuine bugs.I've also got rid of
filter_input
, since, without interpolation, this is equivalent tosel
(although I'm keepingAbstractAgent.filter_input
for now as this serves another purpose)Interpolation is still required for the following:
interpolation_mode
parameter. I've updated the documentation for this parameterinterpolation
method specified in the settings file. It now is and I've updated the documentationcliff_retirement_profile
, so there's no need for sectors and agents to have aninterpolation
attribute. I've created the helper functioninterpolate_capacity
to make this consistentregressions
module - I'm not really sure what this module is doing and don't want to change it, but I think it's fine for nowNot sure why, but this appears to have fixed a bug with prices in the trade model (at least I think it was a bug - R2 prices were suspiciously high before). Won't think too much about it now as that model still needs a lot of work, but encouraging
Fixes #265
Type of change
Key checklist
$ python -m pytest
$ python -m sphinx -b html docs docs/build
Further checks