Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

c_CES_calibration_new_structure leads to vm_cesIO infeasibilities #751

Open
0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q opened this issue Apr 13, 2022 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q
Copy link
Member

0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q commented Apr 13, 2022

From the REMIND Calibration Kindergarten channel:

The calibration calculates efficiency parameters for the CES function such that with given prices the prescribed quantities would be met. Over the iterations, prices (which are basically some complex output from the energy system module in this context) converge towards some equilibrium and the calibration is done. (We just do 10 iterations and encourage people to look whether the calibration results are OK.)
The prices are calculated analytically from the derivative of the CES function of the previous run. If the CES structure changes, i.e., there were CES nests added, there is no derivative for these added nests and thus no prices.
c_CES_calibration_new_structure <- 1 forgoes the calculation of derivative step and uses c_CES_calibration_default_prices for everything instead. Not as good as prices from the .gdx, but better than no prices at all.

During the calibration, on the very top of the CES tree (inco . (lab, en, kap)), the labour price is a slack variable that is adjusted to ensure that the Euler identity holds. If the sum of values (price × quantity) of en and kap is higher than inco, the price would be adjusted to be negative, and the calibration breaks.

In that case, using c_CES_calibration_new_structure and sufficiently low default prices is the recommended remedy.

This, however, can lead to infeasibilities in the CES function. Case in point, the calibration targets for gases/hydrogen in buildings (fegab, feh2b) in SSA in 2010-15 are on the order of 1e-5. Combined with the default setting for c_CES_calibration_default_prices of 0.01, the sum of their values (quantity × price) is about 2e-7, well below the default lower bound for production factors in vm_cesIO of 1e-6. "True" prices for fegab/feh2b in that region and time period seem to be in the range of 0.17–0.32, which would steer them clear of the infeasibility.

@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q 0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q added the bug Something isn't working label Apr 13, 2022
@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q
Copy link
Member Author

Possible solutions:

  1. Choose a c_CES_calibration_default_prices high enough to satisfy the Euler equation on the CES function, but still low enough to avoid ξ < 0 errors. But this is essentially guess work.
  2. Do not use the c_CES_calibration_new_structure crowbar for ξ < 0 issues, which ultimately stem from higher FE trajectories from new input data being combined with not low enough prices from old runs.
    The idea is to:
  • add a factor s29_ppf_price_multiplicator that is multiplied to derived CES prices in the first CES iteration
  • would normally be 1
  • but chosen such that the value (price × quantity) of en and kap, which via the Euler equation equals the sum of values of all ppf except for lab, would be no more than 80 % of inco, leaving a 20 % income share for labour in the first CES iteration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant