update MAgPIE start config

[flohump]

Purpose of this PR

Type of change

(Make sure to delete from the Type-of-change list the items not relevant to your PR)

• Bug fix
• Refactoring
• New feature
• Minor change (default scenarios show only small differences)
• Fundamental change
• This change requires a documentation update

Checklist:

• My code follows the coding etiquette
• I performed a self-review of my own code
• 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 the reporting in remind2 where it was needed
• I adjusted forbiddenColumnNames in readCheckScenarioConfig.R in case the PR leads to deprecated switches
• I checked the log.txt file of my runs for newly introduced summation, fixing or variable name errors
• All automated model tests pass (FAIL 0 in the output of make test)
• The changelog CHANGELOG.md has been updated correctly

Further information (optional):

• Runs with these changes are here:
• Comparison of results (what changes by this PR?):

[laurinks]

Thanks, @flohump, for updating and streamlining the coupled config for ScenarioMIP!

For the documentation, I think it would be helpful to note down what changed content-wise and what changed only in terms of naming. Here is my attempt.

Renaming/restructuring:

1. s32_aff_plantation: Switch replaced by setting AR-plant / AR-Natveg in column f
2. s32_npi_ndc_reversal and s35_npi_ndc_reversal replaced by setting NPI-revert in column f
3. Setting SDP-MC|SSP1-POP-GDP renamed to VLLO in column f

Content changes:

• AR-plant as new default for VLHO scenario.

Could you add a link to an explanation of s32_planning_horizon (used of VLHO variant) and s29_treecover_target and briefly comment on the choices? And for the renaming of the column to f ?

[laurinks]

Two more questions:

1. Should we make analogous changes to scenario_config_coupled.csv (as we are trying to keep the default REMIND scenarios (standalone and coupled) closely harmonized with ScenarioMIP scenarios)?
2. Is it fine to keep the elastic demand for now or should we switch it off for the next test runs (with the goal of switching back on for the next submission runs - if tax recycling available by then)?