I have seen many scholars use CPLEX solver in GAMS as they can solve the problem with ILOG CPLEX software. So in this case,they should possesses same results?
Using GAMS, AMPL, ILOG OPL or any other is just a matter of taste. Results depend on the problem and the solver, and different executions of the same problem should return the same value (or pretty similar, if the optimal cannot be found -remember ILPs are NP-hard-) for the objective function, whereas values for decision variables may vary if there are multiple optimal solutions (or if a suboptimal solution is returned).
In my opinion, cplex solver in GAMS and CPLEX software are used in order to solve the LP and MIP problems. Therefore, the results are same which is global optimal of solution.
Dear Iman, I am in the same page with others, but I believe the benefit is with the computational cost neither so much to do with different packages not did with the quality of solution !. But the matter is with solver, I guess, for example, If you try a large problem with Cplex , GURUBI and LocalSolver the differences are quite distinguished.
GAMS itself is just a modeling language as there are others having been mentioned above (e.g. AMPL).
You can of course use the C callable library or the C++ library of CPLEX directly, if you like to have your model produced directly via a C/C++-program.
If that's easier for you, go with it. If you like the OPL modeling language of CPLEX, it might be your favourite.
The solver itself will always be the same as long as you choose the CPLEX solver from GAMS or AMPL.
It just depends on what you have at your disposal (i.e. what licenses for modeling languages/solvers you got) and what kind of modeling you like better.
In principle, when modeling a problem with different modeling languages (such as GAMS, AMPL), you can expect that a global solver, such as CPlex, will return the same objective function value, no matter what modeling language you used. But...
The solution process within Cplex is different, when you present the variables and constraints in a different ordering. And you have no control about the ordering of those (i.e. the interface between the modeling language and the solver), and even if you would have that kind of control, there's no general strategy to find a good ordering (for example, and ordering that leads to minimum runtime).
What does that mean for you? In case you have an easy problem with a unique optimum, you would not feel much difference from using different modeling languages or different MIP solvers.
In case you have multiple optima, you might get different solutions from different modeling languages (although, of course, they have the same objective function value).
In case your problem is too difficult to find a global optimal solution in finite time, and you terminate the solution process prematurely, then you will easily end up with very different solutions and very different objective function values, depending on the modeling language you have used.
I really enjoyed the question. It is a hard question to answer and I could not find a paper about it. I think there is a difference. For example, if you want to use CPLEX via OPL environment, you can access some inside heuristics (adding some cuts by activating an option) that are deified in CPLEX, and can be really useful. In other software there might be the same solver, but I do not think that the same enhancements are reachable. Besides, even though the software are coded with the same algorithm, different ways of coding by the company (GURABI,CPLEX,...)may lead to different CPU time.
the original question was just concerning different ways of using CPLEX as a solver - Gurobi is a completely independent solver (though the principal authors were the original authors of CPLEX) containing other techniques like cuts and other heuristics - so the branching tree will be different and thus the speed.
There is a lot of parameters for both solvers, which influence the solving process.
Btw.: the parameters of CPLEX are not only accessible within the OPL graphical interface, but also in the different programming API's and e.g. by specifying a parameter file cplex.prm in the GAMS modelling language - as it is the case with Gurobi.
Armin's answer pointed to another source of differences in the branching decisions: the ordering of variables in the model. The choice of the next variable to be branched on may depend on that, leading to a completely different branching tree in the sequel - and thus might lead to quite big differences in the solving time.
You'll find hints to the dependence of the branching process on the seed for the pseudorandom number generator used to break ties in these choices when reading about the tune tool.
The same effect is also triggered by the ordering of variables in the model.
So even when generating the same model in a file format by yourself, the LP and MPS formats mostly lead to different variable orders. While in the MPS format the order of variables is explicitly defined by the format, in the LP format the order is defined by teh order of encountering new variables while reading the file - so it will depend also on the order of constraints in the file.