Monday, July 30, 2012

AMPL-GAMS conversion

The discussion in http://www.or-exchange.com/questions/6021/translate-ampl-code-to-gams is a little bit painful to watch.

First of all there are a number of (small) syntax issues. It is always difficult to write error-free GAMS (or C, Fortran, ….) code without compiling it. I remember from college an exam where we were shown some Pascal code and we were supposed to identify all syntax error. This was not an easy task. This is clearly something a compiler is better at than a human being. In general when presenting some code, it is often good to test it first and see if it at least passes the compiler without syntax errors.

My second point is more substantial. I believe a line-to-line translation will often lead to poor models and unsatisfactory results. It is better to take a step back and re-implement the actual purpose and intent of the original model than to stick to the precise way it was implemented. I have been involved in converting dozens of non-trivial models, and I would say that is the main lesson from those exercises.

Finally the AMPL model is not really well-posed. An equation like:



param h := 11;
var t >= -3.1416, <= 3.1416;
t_r : cos(h*t) = 1;




should raise some questions. I believe the meaning is:


image


This is better implemented as an MINLP. (Or it can be enumerated in this particular case).



If the proposed NLP formulation would be any good then we no longer would need MIP solvers! This is in the same league as using x*(1-x)=0 to model a 0-1 restriction. Actually it is even worse in some respects.



Probably before worrying about a GAMS translation it would be good to go back to the drawing board and improve the model.