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

Add "dynamic" italian scenario & add new flow cap rate limit #19

Merged
merged 8 commits into from
Jul 19, 2024

Conversation

brynpickering
Copy link
Member

Since so much of the underlying data remains the same for a "stationary" vs "dynamic" italian model, it seems to make sense to rely on the same model, just with scenarios to add in additional functionality.

This PR adds in a "dynamic" scenario, which involves setting a maximum rate of capacity expansion for certain technologies. This stops massive jumps in technology capacity between investment steps, although setting the rates to something sensible will require some research.

Copy link
Collaborator

@irm-codebase irm-codebase left a comment

Choose a reason for hiding this comment

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

This is a nice idea, but I would rename this to "constrained", not dynamic.

A dynamic problem has its characteristics evolve over time. In this case all we want is to constrain it. This is also why I am arguing for a constant growth rate.

@@ -198,6 +198,20 @@ constraints:
final_step:
- expression: get_val_at_index(timesteps=-1)

limit_flow_cap_new_max_rate:
Copy link
Collaborator

Choose a reason for hiding this comment

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

This constraint is problematic since it will disallow the installment of technologies that do not have initial capacity at 0. The solution other models use is to add a "seed" value that sets an allowed max initial install.

See here: https://temoacloud.com/temoaproject/Documentation.html#temoa_rules.GrowthRateConstraint_rule

Copy link
Member Author

Choose a reason for hiding this comment

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

I catch this below (where: investsteps=get_val_at_index(investsteps=0) AND flow_cap_initial > 0). If there is no initial flow cap, there is no constraint in the first timestep.

@@ -189,7 +189,7 @@ techs: # Color scheme is Tol Qual Muted + some extras

# RSE, 2015 values
cost_flow_cap.data: 1451 # EUR2010/kW
cost_om_annual.data: 38 # EUR2010/kW/yr
cost_om_annual.data: 38 # EUR2010/kW/yr=
Copy link
Collaborator

Choose a reason for hiding this comment

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

accidental keystroke?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's start by setting the growth rate to be the same constant (0.5?) for everything.

These values are often used by modellers to "tune" results, and there is no agreed measurement for them. They are neither physical or economical "properties" of anything, and they may mask formulation issues (e.g., EoH, extreme discounting).

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure

@brynpickering
Copy link
Member Author

This is a nice idea, but I would rename this to "constrained", not dynamic.

Agreed the naming is murky. I'd argue that the "stationary" model is also "constrained" though. It sets a progressively lower available initial capacity per investment step.

Maybe I expunge the dynamic scenario so that it's just the override for adding a maximum new cap rate that's available. I.e. we don't try to define whether the model is stationary, dynamic, constrained, etc.

@irm-codebase
Copy link
Collaborator

That would work.
Having the distinction between static and dynamic is still useful when testing EoH, though.

We should ensure that the base case is not dynamic in that sense.

@brynpickering brynpickering changed the base branch from clean-italy-parsing to main July 19, 2024 11:05
irm-codebase
irm-codebase previously approved these changes Jul 19, 2024
@brynpickering brynpickering merged commit 1053d87 into main Jul 19, 2024
6 of 7 checks passed
@brynpickering brynpickering deleted the italy-dynamic branch July 19, 2024 11:22
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