read in corrected IEA_ETP notebooks

[fbenke-pik]

No description provided.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Two points:

• Like I said in the meeting, I would like to do a full comparison, so calibration + NPi + PkBudgs and compare scenarios plots. But there seems to be some madrat SNAFU preventing running REMIND with the data you generated, so we need to redo it.
• Your changes would break old mrremind versions, as it requires to replace the files, which are not compatible.

I would therefore opt to add a parameter to readIEA_ETP() (and therefore calcIEA_ETP()) to explicitly select the version of the IEA ETPs to read, have it default to the "broken" version, and explicitly load the "new" version everywhere in mrremind. Ugly, but that is the structure we are cursed working with.

[fbenke-pik]

preventing running REMIND with the data you generated, so we need to redo it.

According to Lavinia you can simply rename the generated files, if the additional hash in the names is the only problem.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Sure. "Rename some files manually" is a cherished component of any reproducible science workflow …

[fbenke-pik]

I was just proposing renaming the specific output file as a quick fix so we don't have to start inputdata generation again.

[fbenke-pik]

I would therefore opt to add a parameter to readIEA_ETP() (and therefore calcIEA_ETP()) to explicitly select the version of the IEA ETPs to read, have it default to the "broken" version, and explicitly load the "new" version everywhere in mrremind. Ugly, but that is the structure we are cursed working with.

On it

[fbenke-pik]

I would therefore opt to add a parameter to readIEA_ETP() (and therefore calcIEA_ETP()) to explicitly select the version of the IEA ETPs to read

Looks like readSource does not accept custom parameters (e.g. version). So if we wanted to make the version part of the input params, it would have to be via subtypes. This would blow up subtype values from 4 to 8 (4 subtypes x 2 version numbers).

Your changes would break old mrremind versions, as it requires to replace the files, which are not compatible.

If this is the only concern, there are other ways to ensure backwards compatibility. I adjusted the structure of the source file on the cluster so that older versions of mrremind read the faulty data and this takes the new data (v1.1)

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

I checked REMIND v3.2.1.dev902 with input data 6.68-A (dev) and 6.68-B (ETPfix) and the results match what was expected.
compScen-dev_ETPfix-2024-02-04_21.33.19-H12.pdf

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Here is the code used for the test, updated to origin/master. fbenke-pik#2

[fbenke-pik]

Here is the code used for the test, updated to origin/master. fbenke-pik#2

Ah sorry, I missed that.