Avoiding incompatabilities between exoGAINS and remind2

[fschreyer]

Hi all,

there had been some incompatibilities between exoGAINSAirpollutants.R and the latest update of the remind2 library which caused REMIND to break, although the package was tested with convGDX2MIF() before.

The reason was that a new output parameter was used in REMIND which is already declared when exoGAINS is run here in the first REMIND iteration but has zero values because it is only filled in 37_industry/realization/postsolve.gms, so after exoGAINS ran. In the input.gdx it was not yet contained because the parameter was just added recently. In the future, some more operations of this kind (introducing a parameter in GAMS in postsolve which will subsequently be used in the reporting) might make sense for the reporting, so it is good to be aware of that.

My suggestions would be, either:

• If exoGAINSAirpollutants.R is only a post-processing which does not feed back to REMIND, it would make sense to include it in the reporting. This would avoid these incompatabiltiies which have broken REMIND from time to time already with reporting changes. Does exoGAINSAirpollutants.R need to be run during a REMIND run, @rauner ?

• If it does need to be run during REMIND runs. Could it be run only starting in the second iteration? This would circumvent the problem of some variables being declared but no values been assigned yet.

• If it does need to be run in the first iteration: It would be great to have a way of testing new reporting version with a REMIND version before it is merged to avoid these issues. We would need to keep in mind to also add if-clauses in reportXX functions which check for whether all elements of a parameter are zero if it is newly introduced.

Best, Felix

@LaviniaBaumstark @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q @giannou @rauner

[rauner]

There were reasons when it was set up to run it iteratively. Will check with the relevant people if these still exist.

[rauner]

Iterative running exogains is necessary for the cooling effect of air pollution for MAGICC for SCC runs. Easiest solution is to only run it from the 2nd REMIND iteration on.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

If exoGAINS does not depend on any calculations based on o37_demFeIndSub, then the problem is solved already.
If exoGAINS does depend on o37_demFeIndSub calculations, then it is now inconsistent with REMIND. We need a review (preferably a refactoring) of exoGAINSAirpollutants.R.

[fschreyer]

If exoGAINS does not depend on any calculations based on o37_demFeIndSub, then the problem is solved already.

Well, it does not depend on that but i would still say that running exoGAINS after the second iteration avoids issues like this in the future ( if some other parameter in GAMS is introduced which is not in input.gdx and only filled in postsolve).

@rauner Could you implement exoGAINS not to run in the first iter?

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

i would still say that running exoGAINS after the second iteration avoids issues like this in the future ( if some other parameter in GAMS is introduced which is not in input.gdx and only filled in postsolve)

… which would introduce inconsistencies between aerosols/exoGAINS and the rest of the model, since it would use last iteration's results again. Probably not by much, but this stuff keeps piling up. Plus, if that happens, we would be non the wiser until somebody spends some serious time looking into this again, because it would fail silently.
I would opt for stopping REMIND if exoGAINSAirpollutants.R fails instead. This way we will know when changes in either REMIND or the R packages break exoGAINS through the AMT runs, and can act upon it.

 *** Calcualte AP emissions
 Execute "Rscript exoGAINSAirpollutants.R";

+if (errorLevel > 1,
+    abort "exoGAINSAirpollutants.R failed";
+);
+
 *** Read input ref results for tall with following dimensions: pm_emiAPexsolve(tall,all_regi,all_sectorEmi,emiRCP)
 if((cm_startyear gt 2005),
 Execute_Loadpoint 'input_ref' p11_emiAPexsolveGDX =  pm_emiAPexsolve;

https://github.com/0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q/remind/commit/b6c05ec767b69ed02d62cf9f7a800f64a184eddb

[rauner]

@fschreyer are you happy with exogains failing as implemented by Michaja or would you still like the 2nd iteration start?

[fschreyer]

Well ok, let's do it like this.