Add switch to load pm_cesdata from input gdx

[johanneskoch94]

Add switch to enable loading pm_cesdata from the input gdx.

This switch should be particularly useful when passing "exploratory" calibration runs (by that I mean calibrations with code changes not reflected in the CES_configuration string) to a policy cascade. Instead of having to make sure that an appropriate .inc file exists, pm_cesdata is simply loaded from the input gdx (easily specified in path_gdx). This also allows for the calibration and policy runs to be submitted in a cascade in a single config.

For now, I'm not worrying about avoiding all the steps linked to the CES_configuration string and a now-useless .inc file. Instead pm_cesdata is simply loaded right after the loading from the .inc file. Do you think this is OK? Or do you see potential issues? Any comment/suggestion is welcome!

[robinhasse]

Thanks for this effort, @johanneskoch94! This additional functionality really only is for convenience during development and not for production runs. Therefore it might not have to cover all edge cases and it can definitely help in specific situations. Still I wonder if you should make the switch more flexible. Right now, it can only take CES coefficients from input.gdx, right? Is this really practical for cascades (and I understood this is your use case)? You assume that all runs of a cascade have the same input.gdx, otherwise they don't share the same calibration. I cannot judge if this assumption usually holds.
Otherwise, the switch could take a path to any gdx. But then you'd have to copy this first (e.g. as calibration.gdx) to the run folder and read the coefficients from there...

[johanneskoch94]

Your suggestion would open up more options, that's true, but I wonder if it is worth the effort... In "my use-case-cascade" not all runs need to have the same input.gdx: As long as they take runs as input.gdx, that were previously started using the calibration gdx as input.gdx (so simply being further along the cascade so to speak), they will get the same pm_cesdata parameters (assuming here that pm_cesdata isn't modified in remind, which shouldn't be the case). What wouldn't be possible is to start a run from an input.gdx that used a different set of pm_cesdata, but does this use case ever happen?

[fschreyer]

In the standard config/scenario_config.csv there are several non-SSP2 runs that have an SSP2 scenario as path_gdx. Not sure exactly why this is. I always thought that it would make sense to choose SSP3 input GDXs for SSP3 as its the closest. But as Robin said, this would be problematic under your setting. If it helps you in development, why not.

But, you are aware of the make set-local-calibration functionality? After adding new CES parameters to your local folder, you can then simply specify different settings of the CESandGDXversion flag in your config and you get the same.

[johanneskoch94]

Thanks Felix! Not sure why SSP3 runs are started from SSP2 runs... sounds fishy to me ;) But yeah, I'm aware that there exists a local-calibration functionality, but I confess that I haven't used it before. (And even the perhaps small entry barrier seemed too high to me 🙃). Also, I really would like to be able to set up a "calibration-with-policy" cascade, which I don't think is possible at the moment, like at all, or am I wrong?