remove and refactor tax-related input files

[fbenke-pik]

Purpose of this PR

This PR removes corrections to taxes and subsidies done via three input input files:

• f21_max_pe_sub.cs4r
• f21_prop_fe_sub.cs4r
• f21_max_fe_sub.cs4r

As these corrections apply to data in the input files only , they can be done directly in mrremind and do not have to happen in REMIND itself.

See the corresponding PR in mrremind: pik-piam/mrremind#714

These changes should have practically no effect on the run results. See comparison to latest AMTs for selected scenarios here:

/p/tmp/benke/model/remind_tax/compScen-SSP2corrected-2025-08-06_14.32.24-H12.pdf
/p/tmp/benke/model/remind_tax/compScen-SSP1-2025-08-06_13.39.46-H12.pdf
/p/tmp/benke/model/remind_tax/compScen-SSP3-2025-08-06_13.40.57-H12.pdf

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:
• Comparison of results (what changes by this PR?):

[laurinks]

Thank you, @fbenke-pik, for cleaning up this part of the code!

These changes should have practically no effect on the run results.

I have checked the compare scenario PDFs and there happen to be larger effects in the concerned regions for all SSPs. IND, LAM and MEA are the strongly affected regions, and looking at calcFEtaxes, one sees that these are among the regions for which changes are applied.

I do not know why these differences occur while your changes should in principle be equivalent to the previous implementation. It could be either (a) some error in the new implementation (unit conversion, values, etc.), or (b) that it is not equivalent to apply the changes in the preloop in GAMS or in the R input data pre-processing.

Maybe @Renato-Rodrigues or @robertpietzcker can provide an input on (b).

In more detail for SSP1: /p/tmp/benke/model/remind_tax/compScen-SSP1-2025-08-06_13.39.46-H12.pdf
Here, one sees the effect on the PE extraction side and when looking into FE|Gases and FE|Liquids, mostly in industry.

SSP2 also shows larger effects, here for FE|Gases.

Same for SSP3.

[fbenke-pik]

Hey Laurin, thanks for taking a look.

These changes should have practically no effect on the run results.

Sorry, that was an incorrect statement. I indeed changed one thing that apparently affects the results.

In mrremind, I removed a unit conversion from $2005 to $2017 applied to the tax limits (here), but I think the conversion should not be there in the first place. It was introduced by me when applying the unit conversion for all input data and in that particular case, it most likely does not make sense for maxFeSubsidy and is definitely wrong for propFeSubsidy (as this is a factor that should not be converted).

So, it is ok if some of the trajectories look different. In theory, they should be more accurate due to the fix.

The actual question is: are there any problematic changes? If so, the way forward would probably be adjusting the limits in mrremind.

By removing the conversion, the max limits should be lower than before.

[laurinks]

Thanks for pointing this out, @fbenke-pik !

The actual question is: are there any problematic changes?

While I am definitely not an energy expert, the changes are problematic in my view because the new runs are much worse in matching (trends in) historical IEA data. For example, one sees this when looking at FE|Gases, FE|Industry|Gases and FE|Industry|Liquids in MEA.

Am I correct that you did not re-calibrate the model, right? It might well be that re-calibration resolves the issue and brings the trajectories in historic timesteps back together.

[fbenke-pik]

I could think of two things to do:

1. If you are certain that recalibration is necessary, I can do that and start new runs.
2. In mrremind, I can set the values that currently end up in input data, not the values that are read in from the sources. This should result in producing the old trajectories (but we also keep any inaccuracies from previous calculations).

[laurinks]

1. If you are certain that recalibration is necessary, I can do that and start new runs.

If the unit conversion should not be there, I believe it is worth re-calibrating and comparing the results. However, I would refer to @LaviniaBaumstark, @JakobBD, or @robertpietzcker for a more qualified judgement on how this change impacts calibration.

[fbenke-pik]

Close in favour of #2207