RE: [AMPL 12278] Speed-up in decomposition algorithms

19 views
Skip to first unread message

Robert Fourer

unread,
Jul 14, 2016, 6:03:32 AM7/14/16
to am...@googlegroups.com
There is a facility developed for our BARON interface, but that works with any solver, which makes it possible to change the variable bounds without writing the problem file again. It is not currently public but we could document it and make it available. However there is not a more general facility of this kind, for changing other problem data.

Any scheme for updating data will require a certain amount of overhead, and AMPL's routines for writing the problem file are quite efficient. If you would like to compare the problem file writing overhead to the other processing times involved, you can turn on "option times 1;" to get some detailed timing output.

Bob Fourer
am...@googlegroups.com

=======

From: am...@googlegroups.com [mailto:am...@googlegroups.com] On Behalf Of arildh...@gmail.com
Sent: Thursday, July 7, 2016 7:39 AM
To: AMPL Modeling Language
Subject: [AMPL 12278] Speed-up in decomposition algorithms

I have implemented a sampling based variant of multi-stage Benders decomposition (SDDP) in AMPL, and experience that the computation time is extremely much higher than what is the case for compiled languages. In my implementation, small and identically structured LP problems are solved repeatedly with minor changes in right-hand sides and objective coefficients. I am aware that loops run much slower in modelling languages such as AMPL, but my concern is the overhead associated with writing the complete problem file to the solver for each (slightly revised) problem being solved.

Recently, I came across an improvement in GAMS relating to this issue, documented in an article "GUSS: Solving Collections of Data Related Models within GAMS". It seems like only the relevant portion of the problem can be updated between consecutive calls to the solver.

Does AMPL consider similar extensions as GUSS in GAMS? Do you have any other suggestions (or pointers to examples/previous posts that I might have missed...) to speed up decomposition algorithms?


Reply all
Reply to author
Forward
0 new messages