Thanks for reporting your findings from the experiments. However, am I correct that the experiments were basically only about open source solver performance?
> I am with those who argued there would be big benefits if we could migrate to more open and modern tools - if we can get them to work for us.
I have understood those expected benefits to be referring to migrating the whole TIMES code to Julia (or some other open source modeling environment). Should that not be accomplished, GAMS would be needed anyway, and many open source solvers like HiGHS are already available under GAMS as a free solver options (no solver cost).
> VEDA (GAMS/CPLEX solver) running kea-v2_1_2 : 76 seconds * 7 threads
> Julia (HiGHS solver) running kea-v2_1_2 : 242 seconds * 6 threads
> Python (HiGHS solver) running kea-v2_1_2 : 405 seconds
I am a bit confused about this, because that would seem to suggest that you have already converted the full TIMES code into Julia and Python, but that would sound too good to be true! So, do you mean that the role of Julia and Python is here limited to reading the model from the file TIMES_kea-v2_1_2.lp (written out by GAMS/Cplex) into a Julia/Python model object and then simply solving that with HiGHS? If so, do you in fact see some notable benefit of using Julia/Python for just that purpose (only the solver interface)?
> VEDA (GAMS/CPLEX solver) running kea-v2_1_2 : 8 MB # used by GAMS process. How can this be? Am I missing some of the memory usage?
I suspect that you may be missing the memory use of the Cplex solver process (which is not "gams.exe" but I guess would be gmsgennx.exe).
> $onecho >> cplex.opt [...]
I think editing the solve.mod file is in general not a very good idea (and that location is not even relevant, because $onecho is a compile time directive), but of course could be done for a quick experiment. A better option would be to modify the options file either by the RUN file or by vtrun.cmd (with user commands that can be added into them automatically), if the writelp file should have the casename, or by just creating a new version of the cplex.opt having the writelp option (if a generic writelp file name is sufficient when creating that file). Note also that GAMS convert can also convert the model into a Cplex lp format file.
Anyway, in my view the main issue would be about migrating the TIMES code, while the open source solvers are in fact available to users regardless of that, unless I am missing something? Could you perhaps consider submitting a proposal to the related ETSAP call about a migration evaluation?
> I am with those who argued there would be big benefits if we could migrate to more open and modern tools - if we can get them to work for us.
I have understood those expected benefits to be referring to migrating the whole TIMES code to Julia (or some other open source modeling environment). Should that not be accomplished, GAMS would be needed anyway, and many open source solvers like HiGHS are already available under GAMS as a free solver options (no solver cost).
> VEDA (GAMS/CPLEX solver) running kea-v2_1_2 : 76 seconds * 7 threads
> Julia (HiGHS solver) running kea-v2_1_2 : 242 seconds * 6 threads
> Python (HiGHS solver) running kea-v2_1_2 : 405 seconds
I am a bit confused about this, because that would seem to suggest that you have already converted the full TIMES code into Julia and Python, but that would sound too good to be true! So, do you mean that the role of Julia and Python is here limited to reading the model from the file TIMES_kea-v2_1_2.lp (written out by GAMS/Cplex) into a Julia/Python model object and then simply solving that with HiGHS? If so, do you in fact see some notable benefit of using Julia/Python for just that purpose (only the solver interface)?
> VEDA (GAMS/CPLEX solver) running kea-v2_1_2 : 8 MB # used by GAMS process. How can this be? Am I missing some of the memory usage?
I suspect that you may be missing the memory use of the Cplex solver process (which is not "gams.exe" but I guess would be gmsgennx.exe).
> $onecho >> cplex.opt [...]
I think editing the solve.mod file is in general not a very good idea (and that location is not even relevant, because $onecho is a compile time directive), but of course could be done for a quick experiment. A better option would be to modify the options file either by the RUN file or by vtrun.cmd (with user commands that can be added into them automatically), if the writelp file should have the casename, or by just creating a new version of the cplex.opt having the writelp option (if a generic writelp file name is sufficient when creating that file). Note also that GAMS convert can also convert the model into a Cplex lp format file.
Anyway, in my view the main issue would be about migrating the TIMES code, while the open source solvers are in fact available to users regardless of that, unless I am missing something? Could you perhaps consider submitting a proposal to the related ETSAP call about a migration evaluation?