Enable and revise switches on CO2 capture, utilization, and storage assumption

[tabeado]

Purpose of this PR

The switches disabling CO2 capture, geologic CO2 storage, and CO2 utilization led to infeasibilities. This PR revises the implementation by avoiding infeasibilities, improving consistency of switch naming, and improving clarity of switches.

Refactoring and Standardization of Carbon Capture Parameters:

• Renaming of switches:
  • cm_ccapturescen --> c_co2captureEnergy
  • cm_IndCCSscen --> cm_co2captureInd
  • cm_CCS_cement --> cm_co2captureCement
  • cm_CCS_chemicals --> cm_co2captureChemicals
  • cm_CCS_steel --> cm_co2captureSteel
  • c_regi_capturescen --> c_regi_co2captureEnergy
  • cm_CCS_markup --> cm_co2captureEnergyMarkup
  • cm_Industry_CCS_markup --> cm_co2captureIndMarkup
• Adjustment of cm_ccapturescen (c_co2captureEnergy) application
  Turning off carbon capture via this switch (i.e. =2) so far meant that also geologic storage was turned off and that vm_emiCDr.l was set to 0 in carbonRemoval/portfolio/presolve. Now, this switch really just adjusts the carbon capture of the teCCS technologies, i.e. energy conversion technologies with CCS in the core. Any other carbon capture technologies - in industry, dac, and oae - have to be set separately; and geologic storage and CCU are also operated individually.
  This is clarified in the switch description, provides greatest flexibility without adding new switches, and avoids unwanted conflicts.

Updates of bounds to fix infeasibilities when turning off technologies
Turning off carbon capture, geologic storage, and CO2 utilization led to infeasibilities because the variables were fixed to 0 for all t. Instead of fixing capacities, upper bounds on vm_deltaCap are now set to sm_eps.

Type of change

Indicate the items relevant for your PR by replacing ◻️ with ☑️.
Do not delete any lines. This makes it easier to understand which areas are affected by your changes and which are not.

Parts concerned

• ☑️ GAMS Code
• ◻️ R-scripts
• ☑️ Documentation (GAMS incode documentation, comments, tutorials)
• ◻️ Input data / CES parameters
• ◻️ Tests, CI/CD (continuous integration/deployment)
• ☑️ Configuration (switches in main.gms, default.cfg, and scenario_config*.csv files)
• ◻️ Other (please give a description)

Impact

• ☑️ Bug fix
• ◻️ Refactoring
• ◻️ New feature
• ◻️ Change of parameter values or input data (including CES parameters)
• ☑️ Minor change (default scenarios show only small differences)
• ◻️ Fundamental change of results of default scenarios

Checklist

Do not delete any line. Leave unfinished elements unchecked so others know how far along you are.
In the end all checkboxes must be ticked before you can merge.

• I executed the automated model tests (make test) after my final commit and all tests pass (FAIL 0)
• I adjusted the reporting in remind2 if and where it was needed
• I adjusted the madrat packages (mrremind and other packages involved) for input data generation if and where it was needed
• My code follows the coding etiquette
• I explained my changes within the PR, particularly in hard-to-understand areas
• I checked that the in-code documentation is up-to-date
• I adjusted forbiddenColumnNames in readCheckScenarioConfig.R in case the PR leads to deprecated switches
• I updated the CHANGELOG.md correctly (added, changed, fixed, removed, input data/calibration)

Further information (optional)

• Runs with these changes are here: /p/tmp/tabeado/remind_fixes/remind
• Comparison of results (what changes by this PR?):

[tabeado]

The switches now work as intended:

Note: cm_captureEnergy = 4 (i.e. no electricity capture) still shows allocation of biomass to "Electricity|w/ CC" but this is not through the bioigccc technology, but through bioftcrec

[tabeado]

@JakobBD please check if the renaming works from your perspective!

[JakobBD]

Generally looks good to me!

Main comment:

To a non-CarMa person, it may not always be instantly clear that "capture" means carbon capture. Could also mean that some sector/phenomenon is captured by the model.

I would opt for carbonCapture instead. E.g., cm_carbonCaptureSteel.
(It's mostly switches, so brevity may not be the first priority)

Runner-ups:

• cCapture, as in cm_cCaptureSteel - has the advantage that c + capture are always perceived as a unit.
• carbCapt or captCarb.

I see that it's not as nice and clean, but the reduced ambiguity outweighs that to me, personally.

Nit-pick:

As far as I know, we are mostly using camelCase in REMIND, and the convention for acronyms at the beginning of a variable name is all lowercase, so ccCost instead of CCcost. Don't know if anyone cares, though. REMIND doesn't have consistent use of camelCase anyways.

[tabeado]

Thanks for making that point, @JakobBD! I checked other switch and variable naming again, and changed it to co2capture as a compromise :)

[lecfab]

Thanks for the consistent renaming!

and the years are restricted to t.val ge cm_startyear

This should not be necessary, as t already does that in core/sets.gms:

t(ttot)     "optimisation time, years between cm_startyear and 2150 with 5 to 20 years time steps",
*** This set includes only the active modeled years, which are the years from ttot greater than or equal to the model run year defined in cm_startyear.
*** t is a subset of ttot and contains only elements defined in ttot.
*** It is a dynamic set:
***    Values are calculated dynamically in GAMS, see a few lines below.
***    t may not be used in certain operations like declarations or equations including lag terms.

...

t(ttot) $ (ttot.val ge cm_startyear) = Yes;

[lecfab]

would add the !! regexp = 0|1 where relevant

[tabeado]

the switch implementation is referring to only ne / eq 1, but I agree that it makes sense. Hope @JakobBD does not mind