Fix issues with the GAMS integration

[andreaslundell]

• [x] Add functionality to communicate the number of threads, tolerances and termination criteria from GAMS to SHOT without specifying an options-file.
• [x] Also some additional pieces of information could still be communicated between GAMS and SHOT. See TODOs in ModelingSystemGAMS.cpp.
• [x] The console output does currently not mention when an options file has been used.

[svigerske]

The GAMS interface currently passes on threads, optca, optcr, reslim, and iterlim from GAMS to SHOT.

There are some more in GAMS that could make it to SHOT, if there is a good fit:

• gevDomLim: stop if so many evaluation errors in nonlinear functions - this may make sense for a pure (local) NLP solver, but normally not for MINLP
• gevNodeLim: should be node limit for single-tree strategy, if > 0 ? how to do this?
• gevCutOff, gevUseCutOff: stop if dual bound is above this value (if I remember right)
• gevCheat, gevUseCheat: extra increment to cutoff bound. Is this MIP.CutOffTolerance ?
• gevTryInt: handling of fractional values in initial solution for repair heuristics

[andreaslundell]

• gevDomLim does not make any sense since I derive bounds on the variables anyway depending on the domain of the functions.
• gevNodeLim can be given as the node limit to the MIP solver.
• gevCutOff could be passed to the MIP solver.
• getCheat could be passed to the MIP solver (at least CPLEX). MIP.CutOffTolerance is the opposite of it.
• I will skip getTryInt at this time.

I will setup the options etc, and then I'll create a PR @svigerske.

[svigerske]

Maybe you can also look at the TODO's at the end of ModelingSystemGAMS::finalizeSolution() :). Two things there:

• I use Results::currentDualBound. Is this always give a valid value, or can it be uninitialized, e.g., if stopping in presolve?
• Can I get the node count from the MIP solver? It would only make sense in the single-tree strategy, I would think.

[andreaslundell]

You want to return the node count to GAMS? They are stored in env->solutionStatistics.numberOfExploredNodes. Note that in the multi-tree strategy, the number of nodes is the sum of the nodes in each individual iteration.

[svigerske]

OK, that's nice.

Is env->solutionStatistics.numberOfIterations ever nonzero? I'm currently using r->getCurrentIteration()->iterationNumber.

We're currently passing the GAMS iteration limit to SHOT in Termination.IterationLimit. I'm not sure what iterations these are, actually, and the limit is by default infinity, but if we could return a corresponding iteration count at the end, that would be nice. Is taking r->getCurrentIteration()->iterationNumber doing that?

[andreaslundell]

The only problem I could see is if there occurs some error before the first iteration (which are LP/MIP iterations) is created. The function getCurrentIteration() only returns the last item of the env->results->iterations vector. So perhaps it would be better to return env->results->iterations.size()?

Actually using env->solutionStatistics.numberOfIterations is better.

[andreaslundell]

I will not implement the gevCheat and gevTryInt parameters now, so I'll close this issue. If there are other GAMS related issues we can create new, more specific, ones.

[svigerske]

Great, thanks. I think there is no need for cheat or tryint, unless there will be a very obvious fit in SHOT.