Warm start from previously solved scenario

[gidden]

This issue would address potential solve speedups (e.g., I am seeing week-long solve times at the moment for some scenarios).

The idea is straightforward - for a scenario which has a solution, provide this existing solution as a "warm start" (i.e., providing a starting basis) for a new scenario run.

In principle, all components for this are available, but need to be connected properly. The steps would be as follows:

1. declare base scenario to use
2. read base scenario solution
3. construct warm-start basis from solution
4. provide new basis to solver (which may require writing a file to disk)

This could be one way to greatly speed up the existing global message experimental set up (which requires multiple sequential solves)

cc @OFR-IIASA @khaeru

[OFR-IIASA]

A few thoughts on how this was done in MESSAGEV:

• warm-start requires the scenario which is to be used for this purpose to be provided as "*.bas" file. See documentation
• The file will then need to be passed as an argument to the solver, which can be done via the cplex.opt file. See documentation
• This makes the process for parallel runs difficult, as the same CPLEX.OPT file can be used for two parallel runs. If specifying the basis, then a CPLEX.OPT file will be required for each solving process.
• It is also not possible to use all solving options when using a basis.
• Storing a basis will mean that in addition to the input/ouput gdx files, a "*.bas" file will be created. If this is done for each scenario, then this means a lot of data is stored; this should be avoided.

I saw a guide how this could be tackled from GAMS here.

[khaeru]

• Since most details of interaction with GAMS are handled by ixmp.model.GAMSModel, this issue might be more properly in ixmp. The message_ix subclass only adds a handful of features.
• Since the GAMS GDX I/O is currently in Java underneath ixmp's JDBCBackend, it is probably unnecessarily complex/too costly to try to implement this before we have a pure-Python ixmp backend. That would also necessitate a re-implementation.