Make learning start dates explicit

[simonkrogmann]

Purpose of this PR

This PR adds inco0year which explicitly states the year for which the investment cost inco0 holds. Previously this was supposed to always be 2005 but varied wildly in practice. I also removed ccap0 and replaced it with pm_histCap bounds or hardcoded values in bounds if the former is unavailable.

I fixed a calculation error in the elh2 calculation which assumed to much capacity in 2020:
0.5 GW(el) * 0.65 (elh2 efficiency) * 1e-3 = 0.000325 and not 0.00077
Since this change hasn't propagated to the input.gdx yet, I'm getting bogus costs for elh2. All other investment costs and capacities are almost identical.

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)

Compare Scenarios at: /p/tmp/simonkr/remind/compScen-learning-2026-10-05_15.19.48-H12.pdf

[fschreyer]

Great! Thanks for these much needed steps in setting this straight! Few people understand this code that fast.

I have a conceptual issue with fixing vm_capCum in addition to vm_cap in core/bounds.gms.

Also, let's see that we can get reasonable elh2 costs again. If they are off because your changes haven't propagated to input GDX, set your input GDX to a fulldata.gdx that you produced by putting the path into path_gdx in the config file or replacing the respective GDX files in your config/gdx-files folder (note that files in this folder this may be overwritten again if new input data is downloaded into your repo).

[fschreyer]

Why do we still need to fix vm_capCum for technologies that have not been around in 2005 and whose learning starts later than 2005? This now doubles setting bounds on vm_capCum and vm_cap which can easily lead to inconsistencies / infeasibilities and I think should be avoided.

I'd hope that we can just rely on the vm_cap and vm_deltaCap bounds for those technologies taking the the vm_capCum from the input.gdx.

[simonkrogmann]

We can fix this by setting vm_capCum to 0 in 2005 (or even later), but vm_capCum needs at least one fix somewhere, because Remind is currently not aware of capacity decommissioned before 2005.

[fschreyer]

Thanks for spotting this. The CAPEX trajectory was actually fine, but it may be that this 0.5 GW(el) assumption did not lead to meaningful results.

As specified further below, I think we should take the vm_capCum for all technologies that start learning after 2005 from the input GDX to initialize the learning curve.

If results for electrolysis are off now, I'd be in favor of shifting its inco0_year to 2025 and start with 2200 USD/kW(el) CAPEX in this year as discussed here. The exact cumulative capacity at this year should be close to 2GW(el) (see bounds here). This number is to be updated but I'd see this independent of this operation for now.

[simonkrogmann]

I started these runs yesterday already and now I'm getting only slightly lower investment costs:

And slightly higher capacities:

Maybe we should do the hydrogen updates in a separate PR.