avoiding infeasibilities for years defined at c_H2InBuildOnlyAfter

[Renato-Rodrigues]

Purpose of this PR

Issue:

For years defined at c_H2InBuildOnlyAfter, H2 was being forced to be exact zero. However at calibration time, pm_cesdata(t,regi,"feh2b","quantity") is being set to a value different from zero.

This causes infeasibilities in the model, that can be small enough for certain gdxs to be ignored, but in others not. From my runs this is specially hard for the IND region in my current tests.

Work around:

In this pull request:

• I redefine pm_cesdata(t,regi,"feh2b","quantity") at calibration time to a small value for years that `c_H2InBuildOnlyAfter´ is active, so the model is calibrated considering values for H2 in buildings, and at the same time I define an offset exactly equal to the quantity value so the model ignores this "calibration" only value in the final energy production balance.
• I relax the zero upper bound to avoid approximation issues in the model and use 1e-6 instead for it in the core/bounds.gms file. @robinhasse This should be adjusted to a lower value if 1e-6 is considered yet too big still for H2 use.

Moreover, the entire code block in Additional hydrogen phase in cost at low H2 penetration levels has no function at all if H2 is always forced to be zero as it is in the default configuration used right now, and the CES tree branch from hydrogen should be removed if this is the case. To avoid issues with case where historical data is zero for H2 build use, I set the q36_H2Share equation to be only calculated from 2020 onward.

PS: Fixing things to exact zero in the model should be avoided unless you want to completely remove a variable from the solver. In this case you would need to remove also the above mentioned equations and CES tree branch.

Type of change

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

• Bug fix

Checklist:

• My code follows the coding etiquette
• I performed a self-review of my own code
• All automated model tests pass (FAIL 0 in the output of make test)

[robertpietzcker]

I don't really get the original problem

However at calibration time, pm_cesdata(t,regi,"feh2b","quantity") is being set to a value different from zero.

the way I understand it, quantity and offset_quantity are exactly the same size but opposite sign - so they exactly cancel, thus allowing vm_demFeSector to be fixed to zero and still the CES equation sees the quantities it was calibrated to.

so I don't see what you mean with

I redefine pm_cesdata(t,regi,"feh2b","quantity") at calibration time to a small value for years that `c_H2InBuildOnlyAfter´ is active, so the model is calibrated considering values for H2 in buildings, and at the same time I define an offset exactly equal to the quantity value so the model ignores this "calibration" only value in the final energy production balance

to my understanding this is exactly the situation we have before the PR?

[robertpietzcker]

apart from this "I don't understand it" - if it makes your runs converge faster, I am totally happy with merging it as the H2-use in buildings is anyway turned off by default at the moment

could you add a path to the runs with the new version to the PR?

[Renato-Rodrigues]

I don't really get the original problem

However at calibration time, pm_cesdata(t,regi,"feh2b","quantity") is being set to a value different from zero.

the way I understand it, quantity and offset_quantity are exactly the same size but opposite sign - so they exactly cancel, thus allowing vm_demFeSector to be fixed to zero and still the CES equation sees the quantities it was calibrated to.

so I don't see what you mean with

I redefine pm_cesdata(t,regi,"feh2b","quantity") at calibration time to a small value for years that `c_H2InBuildOnlyAfter´ is active, so the model is calibrated considering values for H2 in buildings, and at the same time I define an offset exactly equal to the quantity value so the model ignores this "calibration" only value in the final energy production balance

to my understanding this is exactly the situation we have before the PR?

I haven’t done the full mathematical derivation to verify this, but my reasoning is that small runtime changes, such as a slight variation in total gas demand, could proportionally affect vm_cesIO values for fegab and feh2b.

If this is true, a proportional change in a numerically significant value of feh2b (e.g., a calibrated equilibrium value like pm_cesdata(t,regi,"feh2b","quantity") = value far from machine zero) is more likely to remain numerically relevant than a change in a value near zero (e.g., pm_cesdata(t,regi,"feh2b","quantity") ≈ 1e-6). This is because the change on total gas demand in buildings, would proportional change the values of fegab and feh2s at vm_ces level, and not the value after subtracting the fixed offsets.

In over simplistic terms,

• 10% increase on feh2b, when its equilibrium value is 100, means an unbalance of 10 after we discount the offset value of 100.
• 10% increase on feh2b, when its equilibrium value is 1e-6, means an unbalance of 0.0000001 after we discount the offset value of 1e-6. Which is a value completely ignored by the solver and does not create an unbalance.

That said, I could be wrong, as I haven't fully checked the math behind this and that this proportionality assumption holds.
However, I can say that empirically the runs I did after this change had the expected results I hoped for and did not show the same issue as before

All of this only makes sense if the real intent behind using the switch c_H2InBuildOnlyAfter is to not have hydrogen in buildings at all, both on business as usual as well as in policy cases.
If this is not the goal, I would strongly recommend on not hard codding fixes to calibrated variables, and instead simply adjust the v36_costAddTeInvH2 cost to parametrize hydrogen penetration in buildings accordingly.
Hard codding parts of the CES tree is bad practice in my opinion.

could you add a path to the runs with the new version to the PR?

Unfortunately, I haven’t organized these runs because I am jumping back and forth trying to deal with other challenges on the calibration in different folders. Some of the runs should be here: /p/projects/ecemf/REMIND/2040_scenarios/v12_2024_09_20_2040paper-rev1_afterTax_6.94/output.