-
Notifications
You must be signed in to change notification settings - Fork 129
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
Remove the splitting of deltacap to two time steps #1238
Remove the splitting of deltacap to two time steps #1238
Conversation
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.
My comments are mainly small changes either improve documentation or be on the safe side to avoid division by zero errors.
***--------------------------------------------------------------------------- | ||
*' calculating the absolute change of output with respect to the value in REF for each te (counting SE, FE, UE and CCS) | ||
q_changeProdStartyear(t,regi,te)$( (t.val gt 2005) AND (t.val eq cm_startyear ) ).. | ||
v_changeProdStartyear(t,regi,te) |
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.
this is very minor, but as by default you only want to define v_changeProdStartyear to a single year always, you could remove the time dimension from the variable and equation, and use a sum to control the time dimension in vm_prodSe, vm_prodFE, ...
It wouldn't change in any way the way your formulation works, but it would reduce unnecessary dimensions from memory allocation and gdx files.
This is very minor in this case, but I just wanted to mention to keep in mind for alternative formulations in the future.
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.
right. I didn't think about this but just automatically added the time dimension (while trying to make sure that only one entry will ever be filled in a run), but you are right - especially if one loads other gdxes from runs fixed until other times, there might be residual information carried over in the gdx, which would be confusing...
I will check if I can remove the time dimension today
core/declarations.gms
Outdated
@@ -354,7 +362,9 @@ vm_costCESMkup(ttot,all_regi,all_in) "CES markup cost to repres | |||
vm_taxrevimplicitQttyTargetTax(ttot,all_regi) "quantity target bound implemented through implict tax" | |||
vm_taxrevimplicitPriceTax(ttot,all_regi,entySe,all_enty,sector) "final energy price target implemented through implict tax" | |||
vm_taxrevimplicitPePriceTax(ttot,all_regi,all_enty) "primary energy price target implemented through implict tax" | |||
|
|||
v_changeProdStartyear(ttot,all_regi,all_te) "absolute change of output with respect to the reference run for each te" |
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.
could you add the units for these variables in between brackets?
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.
done
main.gms
Outdated
parameter | ||
cm_SlackMultiplier "sets the slack size for v_changeProdStartyearSlack" | ||
; | ||
cm_SlackMultiplier = 1; !! def 1 |
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.
could you add the unit for the slack multiplier? if it is just a factor, or it is in percentage terms?
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.
done
core/equations.gms
Outdated
* ( pm_data(regi,"constrTme",te)$(pm_data(regi,"constrTme",te) gt 0) + 2$(pm_data(regi,"constrTme",te) eq 0)) !! take construction time | ||
; | ||
|
||
*' calculating the resulting costs (which are applied as a tax in module 21, so they have no budget effect but only incluence REMIND choices) |
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.
*' calculating the resulting costs (which are applied as a tax in module 21, so they have no budget effect but only incluence REMIND choices) | |
*' calculating the resulting costs (which are applied as a tax in module 21, so they have no budget effect but only influence REMIND choices) |
…er/remind into deltacapHalf1k_tax
Would someone feel qualified to write some more documentation for these switches? |
Purpose of this PR
Remove the splitting of deltacap to two time steps: from now on, capacity additions in one time step are (again) directly accounted for in the capacities in this time step.
To prevent the model strongly changing the 2025 results in an ambitious climate policy scenario (which would be unrealistic as today is 2023 and changes to policies and investments take time to implement), this PR introduces a new mechanism so that the model sees (budget-neutral) costs when it changes the results in cm_startyear compared to the reference run from which it starts. The costs are a quadratic function of the relative change, to allow small changes put prevent large changes. The relevant equations and variables all contain "changeProdStartyear" in their names.
The parameters c_changeProdCost and c_SlackMultiplier in main.gms determine how close the model wants to stay to the values in the reference run.
Currently, the default is set to c_changeProdCost = 5 and c_SlackMultiplier = 1, but this may be adjusted in the validation in the coming weeks.
As time progresses, these values should be adjusted: c_changeProdCost should be increased in 2024 and 2025 (as the resulting changes possible will become smaller and smaller), until in 2026, cm_startyear is shifted to 2030, at which point c_changeProdCost should be reduced to allow larger deviations from the reference run in 2030.
Type of change
(in the 3.0.0 documentation, the old q_cap and q_transPe2se are printed in full, and they still contain
* pm_omeg(regi,"2",te)
* vm_deltaCap(ttot,regi,te,rlf)
this should be removed/ will be automatically removed when running goxygen again.
Checklist:
remind2
where it was neededFAIL 0
in the output ofmake test
)Further information (optional):
some findings are described in issue https://github.com/remindmodel/development_issues/issues/185