-
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
CDR cleaning session #1154
CDR cleaning session #1154
Conversation
@@ -855,6 +852,16 @@ parameter | |||
; | |||
cm_gdximport_target = 0; !! def = 0 | |||
*' | |||
parameter |
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.
Great to have all these parameters in one "section" here. Would it make sense to rename others also to cm_33*** to indicate that they are only used in module 33, e.g. cm_33gs_ew, cm_33LimRock? Or would this be against our coding etiquette? And what do you think about assembling also other relevant switches here, like cm_frac_CCS, cm_frac_NetNegEmi, c_ccsinjecratescen, c_ccscapratescen?
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 fully agree with cm_33gs_ew, cm_33LimRock, as they're only used in the CDR module. However, I will change it in a separate PR. When it comes to cm_frac_CCS, cm_frac_NetNegEmi, c_ccsinjecratescen, c_ccscapratescen, since these are used in the core, I'd keep them as they are, what do you think?
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.
yes, agree to keep the names for those. It would be nice to have them all in one place close together, but this can be done in a separate PR
221abe2
to
9fc8a28
Compare
@@ -855,6 +852,16 @@ parameter | |||
; | |||
cm_gdximport_target = 0; !! def = 0 | |||
*' | |||
parameter |
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.
yes, agree to keep the names for those. It would be nice to have them all in one place close together, but this can be done in a separate PR
*** SOF ./modules/33_CDR/portfolio/bounds.gms | ||
|
||
vm_emiCdr.fx(t,regi,emi)$(not sameas(emi,"co2")) = 0.0; | ||
vm_emiCdr.l(t,regi,"co2")$(t.val ge 2025 AND cm_ccapturescen ne 2) = -sm_eps; |
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.
Since this eq now applies to all technologies including EW, does it still make sense to tie it to cm_ccapturescen?
what is the status of thsi PR? will you continue working on it? |
I think this one is ready, not sure why it is not yet merged |
I didn't merge it before cause I was away for a month, but now I'm back and merging :) |
Purpose of this PR
In this PR, the
33_CDR
module is refactored from several realizations (each corresponding to a combination of CDR options available in REMIND) to one realization with switches determining which CDR technologies are available. It makes our life easier when we add more technologies to the CDR module :)The new realization is called
portfolio
and the switches to turn on/off the CDR optionscm_33[option abbreviation]
, e.g,cm_33EW
,cm_33DAC
. A set of used CDR optionste_used33
contains technologies determined by the switches and is used for calculations.Removing vm_otherFEdemand
When we add more technologies to the CDR module, it becomes tricky to report the final energy for each CDR using just
vm_otherFEdemand(ttot,all_regi,all_enty)
, since it lacks the technology dimension.vm_otherFEdemand
is replaced byv33_FEdemand(ttot,all_regi,all_enty,all_enty,all_te)
, whereall_te
is a CDR technology. The secondall_enty
is the FE demand of a given technology, e.g., for DAC it would be heat for material recovery and electricity for ventilation. The firstall_enty
corresponds to FE carrier chosen to supply the FE energy demand, e.g., heat for DAC can be provided by gas, H2, wasted heat, or electricity.FE mapping
fe2cdr(all_enty,all_enty,all_te)
has been added to increase the readability of the code.equations.gms
All equations are collected in one structured file. Firstly, equations that consider more than one CDR option are listed. Then option-specific equations follow in the agreed order: capacity, emissions, energy demand, costs, and limits-related. Option-specific equations have names that follow the pattern:
q33_[option abbreviation]_[descriptive enough name]
.Enhanced weathering improvements
rockgrind
has been renamed toweathering
rlf_cz33
(anrlf
subset for the temperature grades for EW) was added to increase the readability of the equationsttot - 1
(look this equation, spotted by Anne).Type of change
Checklist:
FAIL 0
in the output ofmake test
)Further information (optional):