Abort GAMS run on coupling Rscript failure

[tonnrueter]

Purpose of this PR

A bare execute "Rscript ..." stashes the child's exit code in errorLevel but then keeps running. If the R coupling call fails, GAMS continues on to execute_load. The absence of an associated gdx-file is usually the point of failure then. However, in case the coupling script successfully ran at least once GAMS will pick up a stale gdx from a previous iteration. execute.checkErrorLevel makes GAMS abort on any non-zero exit. This is applies to:

• 15_climate/magicc7_ar6/postsolve.gms (interim + impulse response)
• 35_transport/edge_esm/presolve.gms
• 50_damages/KotzWenz/postsolve.gms

Type of change

Indicate the items relevant for your PR by replacing ◻️ with ☑️.
Do not delete any lines. This makes it easier to understand which areas are affected by your changes and which are not.

Parts concerned

• ☑️ GAMS Code
• ◻️ R-scripts
• ◻️ Documentation (GAMS incode documentation, comments, tutorials)
• ◻️ Input data / CES parameters
• ◻️ Tests, CI/CD (continuous integration/deployment)
• ◻️ Configuration (switches in main.gms, default.cfg, and scenario_config*.csv files)
• ◻️ Other (please give a description)

Impact

• ☑️ Bug fix
• ◻️ Refactoring
• ◻️ New feature
• ◻️ Change of parameter values or input data (including CES parameters)
• ◻️ Minor change (default scenarios show only small differences)
• ◻️ Fundamental change of results of default scenarios

Checklist

Do not delete any line. Leave unfinished elements unchecked so others know how far along you are.
In the end all checkboxes must be ticked before you can merge.

• I executed the automated model tests (make test) after my final commit and all tests pass (FAIL 0)
• I adjusted the reporting in remind2 if and where it was needed
• I adjusted the madrat packages (mrremind and other packages involved) for input data generation if and where it was needed
• My code follows the coding etiquette
• I explained my changes within the PR, particularly in hard-to-understand areas
• I checked that the in-code documentation is up-to-date
• I adjusted forbiddenColumnNames in readCheckScenarioConfig.R in case the PR leads to deprecated switches
• I updated the CHANGELOG.md correctly (added, changed, fixed, removed, input data/calibration)

Further information (optional)

c.f. attached mve.gms, coupling.R in mve_checkErrorLevel.zip

This change is difficult to test in a REMIND run, here's a minimum viable experience. Load the PIAM module, place both files in the same folder

Usage

# BUG: bare execute + failed R call -> silently loads the stale gdx (42, not 2)
gams mve.gms --guard=off --fail=1

# FIX: checkErrorLevel + failed R call -> GAMS aborts at the execute call
gams mve.gms --guard=on  --fail=1

# happy path: R call succeeds -> fresh value (2) is loaded
gams mve.gms --fail=0

Expected outcomes

--guard	--fail	R call	GAMS result
off	1	exits 1	continues; loads stale 42; *** Status: Normal completion (+ a >>> STALE gdx warning in the log)
on	1	exits 1	aborts at the execute call (rc =/= 0); *** Status: Execution error(s); never loads
any	0	writes gdx	loads fresh 2; Normal completion

The off/1 runs a bare execute and lets a failed coupling call finish mve.gms with **** Status: Normal completion on stale data, just logs a non-fatal >>> STALE gdxwarning. The end of the run looks fine, but isn't.on/1usesexecute.checkErrorLevel, logs *** Error at line 35: Execution halted: execute.checkErrorLevel returned with 1and finishes with*** Status: Execution error(s)`

[ahagen-pik]

Thank you, @tonnrueter.
Sounds good to me!