Handling vintage availability #10
Comments
|
This is fantastic! For now, I think I prefer version 1. My reasoning:
Ideally, the yaml configuration should be able to support any and all kinds of math. But this is a very hard milestone that will need a lot of careful thought. Version 1 will make that "jump" easier than version 2 because all the complexity is on the side that would be replaced. Basically, version 2 still needs jumping to the python files, so it's just as complex (read-wise) as version 1, but with less flexibility and harder debugging. |
|
Another comment: In theory, we do not really "need" the investstep or vintagestep for this. Instead, what we need is the difference between them. If it was possible to poll these parameters using that difference when constructing the math, you would only need to define the trend once, and not for each investstep/vintagestep relation This can save memory (and make things easier to understand) when you have very fine investment resolutions.
Into this:
This would be useful since the |
|
It's never going to be a particularly large array (timesteps will always win there) so I'm not really concerned about memory. I'm also unsure how |
Makes sense, although with every function the user has to define the LaTex math representation, which you mostly get for free with the YAML math. It's also not as easy to find the helper functions. We can add them to the documentation, but there is a reason we've moved things to YAML; it's easier to read and edit. For now though, we'll go with 1. I wonder whether just allowing the numpy library to be accessed within YAML math expressions ( |
tl;dr: I think the difference in this case depends on how readable we want this to be on the user side. You are right. This won't use too much memory anyhow, so that's not a good argument on my side. However, I think it's important to consider readability. If there is something odd going on, checking a single line instead of a sequence on two dimensions is easier. However, this "age" suggestion would only really work if the sum within the constraint has limits on range (sum from investment zero until the current one). Sort of like this (in pyomo): def c_cap_transfer(model: pyo.ConcreteModel, tech: str, investstep: int):
"""Transfer installed capacity between year slices."""
avail_new_cap = sum(model.cnew[tech, v]*model.available_vintages[tech, investstep-v] for v in model.Investsteps if v <= investstep)
avail_ini_cap = model.inicap[tech]*model.available_initial_cap[tech, investstep]
return model.ctot[tech, investstep] == avail_ini_cap + avail_new_capIf you want the However, if other parameters related to the technology vary too, we will need a new constraint because you can no longer aggregate all years into a single total capacity (unless you give it a vintage index too, and we want to avoid that in the base case). That will happen regardless of how we approach this issue. I guess the current approach is fine, but it might need revisions if other "age" aspects are introduced... |
Ufff... you are right. I agree that helper functions are hard to find... I struggled a bit to find the ones that shift timesteps. So maybe solution 2 is better long-term. Especially if it avoids having to re-define math for LaTeX documentation. The |
What can be improved?
We have to currently input vintage availability manually. Ideally we would input it programatically as part of the math.
I have put together two possible ways we can do it, with different math in the YAML vs in the helper functions. @irm-codebase which do you think is more readable?
Both have this new math to get the year as an integer from the vintagesteps/investsteps (necessary as long as this is still an issue: calliope-project/calliope#567).
YAML math
Helper functions
version 1:
YAML math
Helper functions
version 2:
YAML math
Helper functions
Version
v0.1.0
The text was updated successfully, but these errors were encountered: