ASCEND - User contributions [en]

Category:Outdated

2010-05-17T03:08:33Z

WikiSysop: Replaced content with 'Articles in need of an update...'

Articles in need of an update...

Notes Ubuntu 7.10 Install

2010-05-17T03:08:11Z

WikiSysop:

{{missing}}
{{outdated}}
[[Category:Development]]

Installing LyX

2010-05-17T03:07:51Z

WikiSysop:

{{missing}}
{{outdated}}
[[Category:Development]]

Debugging ASCEND

2010-05-17T03:07:33Z

WikiSysop:

{{missing}}
{{outdated}}
[[Category:Development]]

Building a Debian package

2010-05-17T03:07:13Z

WikiSysop:

{{missing}}
{{outdated}}

See [[dtar]].
[[Category:Development]]

Building a Debian package

2010-05-17T03:07:04Z

WikiSysop:

{{missing}}
{{outdated}}
See [[dtar]].
[[Category:Development]]

ASCEND capabilities

2010-05-17T03:06:38Z

WikiSysop:

{{missing}}
{{outdated}}
[[Category:Documentation]]

TclTk Quick Guide

2010-05-17T03:06:16Z

WikiSysop: Created page with '{{missing}} {{outdated}} Category:Tutorials'

{{missing}}
{{outdated}}
[[Category:Tutorials]]

Template:Outdated

2010-05-17T03:05:47Z

WikiSysop: Created page with '''This page contains content that has been observed to be out-of-date. You can help to update the content, or search for a page containing newer information.'' [[Category:Outdate…'

''This page contains content that has been observed to be out-of-date. You can help to update the content, or search for a page containing newer information.''
[[Category:Outdated]]

Notes Ubuntu 7.04 Install

2010-05-17T03:04:54Z

WikiSysop: Created page with '{{missing}} {{outdated}} Category:Development'

{{missing}}
{{outdated}}
[[Category:Development]]

New Compiler

2010-05-17T03:04:29Z

WikiSysop: Created page with '{{missing}} {{outdated}} Category:Development'

{{missing}}
{{outdated}}
[[Category:Development]]

Category:ASCEND Contributors

2010-05-17T03:03:49Z

WikiSysop:

''Please contact us if you are missing from this list and would like to be added!''
[[Category:Development]]

Non-proprietary Optimisation

2010-05-17T03:02:56Z

WikiSysop: Created page with '{{missing}} Category:Development'

{{missing}}
[[Category:Development]]

Survey of optimisation software

2010-05-17T03:02:35Z

WikiSysop: /* List of Lists */

The following is a survey of optimisation software that was performed as a part of our effort to identify options for a [[Non-proprietary Optimisation]] solver for ASCEND. Feel free to add any that we've missed.

== List of Lists ==

* List of NLP solvers: http://www.ici.ro/camo/hnp.htm
* List of unconstrained optimisation solvers: http://www.ici.ro/camo/huo.htm
* There ''was'' a nice list at http://www.scicomp.uni-erlangen.de/SW/opt.html but the link seems to be broken at the moment.
* 'Decision tree' for optimization software http://plato.asu.edu/sub/nlores.html
* Description of different types of optimisation problems: http://coool.mines.edu/report/node3.html

== Free Open Source Software options ==

* [https://projects.coin-or.org/Ipopt IPOPT] (LGPL) 'Interior-Point Filter Line-Search Algorithm'. Possibly some problems with scaling of variables (according to RPS). can use a number of free and non-free matrix solvers; the free matrix solver in version 3.3.1 is MUMPS. See also [[IPOPT]] in this wiki.
* [http://trilinos.sandia.gov/packages/moocho/ MOOCHO] (GPL?) reduced sequential quadratic programming (SQP); allows the user to supply their own linear solver.
* [http://www.gnu.org/software/gsl/manual/html_node/Multidimensional-Minimization.html GSL 'multimin'] (GPL) several multidimensional dense-matrix unconstrained optimisation methods including conjugate gradient methods, quasi-newton methods, steepest descent and Nelder-Mead simplex method.
* [http://acts.nersc.gov/opt++/index.html OPT++] (free, includes ''optional'' wrapping of non-free NPSOL). Good but dense matrices only (RPS). Superceded by MOOCHO?
* [http://software.sandia.gov/appspack/version5.0/index.html APPSPACK] (GPL?) 'asynchronous parallel generating set search', derivative-free.
* [http://www.eng.buffalo.edu/Research/MODEL/mdo.test.orig/CONMIN/ CONMIN] ('free' but where from?) 'two-step limited memory quasi Newton like Conjugate Gradient method with Beale restarts'.
* [http://www.cs.sandia.gov/SGOPT/ SGOPT] (LGPL) Evolutionary and pattern-search algorithms
* [http://www.math.ufl.edu/~hager/ OPTPACK] (PD) 'a dual algorithm for constrained optimization'
* [http://www.netlib.org/minpack/ MINPACK] (BSD-like) unconstrained
* [http://www.coin-or.org/Bonmin/ BonMin] (CPL) Part of the COIN-OR suite; a solver for convect MINLP problems.
* [https://projects.coin-or.org/Couenne Couenne] (CPL) Part of the COIN-OR suite; a solver for non-convex MINLP problems.
* [http://www.ime.usp.br/~egbirgin/tango/ ALGENCAN] (GPL) Augmented Lagrangian plus an embedded smooth function box-constraint solver called 'GENCAN'
* [http://www.ime.usp.br/~egbirgin/tango/ SPG] (GPL) for smooth function with convex constraint
* [http://www.gerad.ca/~couturgi/NOMAD/ NOMAD] (GPL) Generalized Pattern Search (GPS) algorithms to solve nonlinear optimization problems
* [http://www-fp.mcs.anl.gov/otc/Tools/LBFGS-B/ LBFGS-B] (PD?) limited-memory quasi-Newton code
* [http://ab-initio.mit.edu/wiki/index.php/NLopt NLopt] (LGPL) wrapper for a few other FOSS codes, but also reportedly has some new implementations of certain algorithms
* [http://www.uni-graz.at/imawww/kuntsevich/solvopt/ SolvOpt] (PD) 'method of exact penalisation', based on N.Z. Shor r-algorithm
* [http://openopt.org/ralg ralg] (BSD) - an implementation of N.Z. Shor r-algorithm; nonlinear/nonsmooth constrained/unconstrained problems

'''Wrappers'''

* [http://www.coin-or.org/NLPAPI/index.html NLPAPI] (GPL?) a generalised wrapper for NLP solvers, including support for LANCELOT.
* [https://projects.coin-or.org/GAMSlinks/ GAMSlinks] (GPL?) a wrapper for [https://projects.coin-or.org/ COIN-OR] solvers that allows them to be called from GAMS. This is interesting as it shows how we could implement set up ASCEND so that it can use GAMS solvers, which adapting FOSS solvers that run under GAMS much easier to adapt for use with ASCEND.
* [http://www.netlib.org/ampl/solvers/lancelot/ AMPL/LANCELOT] a wrapper for running LANCELOT from AMPL. Again, this provides a way for seeing how solvers that have been adapted for use in AMPL might be also be connected to from ASCEND.
* [http://cuter.rl.ac.uk/cuter-www/interfaces.html CUTEr] (GPL-like license) is a wrapper for a wide range of optimisation solvers, and also a testing framework.
* [https://projects.coin-or.org/Osi OSI] (CPL?) wrapper for quite a wide range of LP solvers, from COIN-OR.
* [https://projects.coin-or.org/OS OS] (CPL?) Optimisation Services, a number of interface languages and APIs for communicating between problem 'servers' and solver 'clients', with support for a range of COIN-OR solvers and converters for GAMS/AMPL input files.
* [http://wiki.services.openoffice.org/wiki/Optimization_Solver OpenOffice.org's Solver]
* [http://openopt.org OpenOpt] (BSD) a general purpose optimization framework written in Python and NumPy, capable of automatic differentiation.

'''Unknown:'''

* [http://coool.mines.edu/ COOOL]

Another free list: [http://software.sandia.gov/Acro/html/Main/AcroPackages.html]

There are some more listed in the [ftp://rtfm.mit.edu/pub/usenet/sci.answers/nonlinear-programming-faq nonlinear-programming-faq].

== Free for non-commercial use ==

Trust region

* [http://www.numerical.rl.ac.uk/lancelot/blurb.html LANCELOT] (no redistribution or resale) Trust region method, adapt for bound constraints

Active set

* [http://www-unix.mcs.anl.gov/~more/tron/ TRON] (permission to copy and modify, but only to be used for 'internal research' ([http://plato.asu.edu/ftp/other_software/tron_f90.tar.gz download]) active set method that uses a combination of gradient projections and a preconditioned conjugate gradient method to minimize an objective function. TRON only provides for 'box' constraints and has no support for equality constraints, although it may be possible to add support for that by wrapping TRON around an NLA solver?

Sequential quadratic programming

* [http://plato.la.asu.edu/donlp2.html DONLP2] (dense; free for non-commercial purposes)

== Some proprietary alternatives ==

Generalised reduced gradient method:

* [http://www.conopt.com/ CONOPT] (plus others in certain cases)
* [http://www.sbsi-sol-optimize.com/asp/sol_product_minos.htm MINOS] (uses GRG for linear constraints, else 'sparse SLC algorithm (a projected Lagrangian method, related to Robinson's method)' for nonlinear constraints. Used when gradient evaluation is cheap.
* MS Excel [http://support.microsoft.com/kb/q214115/ Solver].
* GRG2
* LSGRG2
* [http://www.pinterconsulting.com/ LGO] 'Lipschitz Global Optimizer'

Sequential quadratic programming:

* [http://www.sbsi-sol-optimize.com/asp/sol_products_snopt_desc.htm SNOPT] (sparse) Used when gradient evaluation is expensive. 'SNOPT employs a sparse SQP algorithm with limited-memory quasi-Newton approximations to the Hessian of Lagrangian. An augmented Lagrangian merit function promotes convergence from an arbitrary point.'
* [http://www.uni-bayreuth.de/departments/math/~kschittkowski/nlpqlp22.htm NLPQLP]
* [http://www.sbsi-sol-optimize.com/asp/sol_product_npsol.htm NPSOL]
* [http://www.sbsi-sol-optimize.com/asp/sol_lssol105description.htm LSSOL] (dense, 'two-phase (primal) quadratic programming')
* [http://www.princeton.edu/~rvdb/ LOQO] (free 30-day trial) 'LOQO is based on an infeasible, primal-dual, interior-point method applied to a sequence of quadratic approximations to the given problem'
* [http://www.mcs.anl.gov/~leyffer/solvers.html FilterSQP]

Active set method:

* [http://www.sbsi-sol-optimize.com/asp/sol_product_qpopt.htm QPOPT] (dense)

Other methods:

* [http://www.ziena.com/knitro.htm KNITRO] (three methods: interior point direct, interior point conjugate gradient, 'active set')
* [http://www.gams.com/dd/docs/solvers/pathnlp.pdf PATHNLP]. 'PATHNLP solves an NLP by internally constructing the Karush-Kuhn-Tucker (KKT) system of first-order optimality conditions associated with the NLP and solving this system using the PATH solver for complementarity problems'. Supposedly good for convex problems.
* [http://www.mosek.com/products.html MOSEK] (limited version available for download, or free student license) Interior point method plus simplex method.
* [http://www2.am.uni-erlangen.de/~kocvara/pennon/ PENNON] 'penalty method', 'PBM method of Ben-Tal and Zibulevsky'

Global optimisation

* [http://www.andrew.cmu.edu/user/ns1b/baron/baron.html BARON]
* [http://www.ganso.com.au/index.php GANSO]

Methods not yet checked:

* IMSL and NAG software libraries
''More to come''

Mixed integer/nonlinear programs:

* [http://www.gams.com/solvers/solvers.htm#DICOPT DICOPT]: MINLP

See also [[Survey of sparse matrix software]]

[[Category:Development]]
[[Category:Miscellany]]

Survey of optimisation software

2010-05-17T03:02:07Z

WikiSysop: /* Free Open Source Software options */

The following is a survey of optimisation software that was performed as a part of our effort to identify options for a [[Non-proprietary Optimisation]] solver for ASCEND. Feel free to add any that we've missed.

== List of Lists ==

* List of NLP solvers: [http://www.ici.ro/camo/hnp.htm]
* List of unconstrained optimisation solvers: [http://www.ici.ro/camo/huo.htm]
* There ''was'' a nice list at [http://www.scicomp.uni-erlangen.de/SW/opt.html] but the link seems to be broken at the moment.
* 'Decision tree' for optimization software [http://plato.asu.edu/sub/nlores.html]
* Description of different types of optimisation problems: [http://coool.mines.edu/report/node3.html]

== Free Open Source Software options ==

* [https://projects.coin-or.org/Ipopt IPOPT] (LGPL) 'Interior-Point Filter Line-Search Algorithm'. Possibly some problems with scaling of variables (according to RPS). can use a number of free and non-free matrix solvers; the free matrix solver in version 3.3.1 is MUMPS. See also [[IPOPT]] in this wiki.
* [http://trilinos.sandia.gov/packages/moocho/ MOOCHO] (GPL?) reduced sequential quadratic programming (SQP); allows the user to supply their own linear solver.
* [http://www.gnu.org/software/gsl/manual/html_node/Multidimensional-Minimization.html GSL 'multimin'] (GPL) several multidimensional dense-matrix unconstrained optimisation methods including conjugate gradient methods, quasi-newton methods, steepest descent and Nelder-Mead simplex method.
* [http://acts.nersc.gov/opt++/index.html OPT++] (free, includes ''optional'' wrapping of non-free NPSOL). Good but dense matrices only (RPS). Superceded by MOOCHO?
* [http://software.sandia.gov/appspack/version5.0/index.html APPSPACK] (GPL?) 'asynchronous parallel generating set search', derivative-free.
* [http://www.eng.buffalo.edu/Research/MODEL/mdo.test.orig/CONMIN/ CONMIN] ('free' but where from?) 'two-step limited memory quasi Newton like Conjugate Gradient method with Beale restarts'.
* [http://www.cs.sandia.gov/SGOPT/ SGOPT] (LGPL) Evolutionary and pattern-search algorithms
* [http://www.math.ufl.edu/~hager/ OPTPACK] (PD) 'a dual algorithm for constrained optimization'
* [http://www.netlib.org/minpack/ MINPACK] (BSD-like) unconstrained
* [http://www.coin-or.org/Bonmin/ BonMin] (CPL) Part of the COIN-OR suite; a solver for convect MINLP problems.
* [https://projects.coin-or.org/Couenne Couenne] (CPL) Part of the COIN-OR suite; a solver for non-convex MINLP problems.
* [http://www.ime.usp.br/~egbirgin/tango/ ALGENCAN] (GPL) Augmented Lagrangian plus an embedded smooth function box-constraint solver called 'GENCAN'
* [http://www.ime.usp.br/~egbirgin/tango/ SPG] (GPL) for smooth function with convex constraint
* [http://www.gerad.ca/~couturgi/NOMAD/ NOMAD] (GPL) Generalized Pattern Search (GPS) algorithms to solve nonlinear optimization problems
* [http://www-fp.mcs.anl.gov/otc/Tools/LBFGS-B/ LBFGS-B] (PD?) limited-memory quasi-Newton code
* [http://ab-initio.mit.edu/wiki/index.php/NLopt NLopt] (LGPL) wrapper for a few other FOSS codes, but also reportedly has some new implementations of certain algorithms
* [http://www.uni-graz.at/imawww/kuntsevich/solvopt/ SolvOpt] (PD) 'method of exact penalisation', based on N.Z. Shor r-algorithm
* [http://openopt.org/ralg ralg] (BSD) - an implementation of N.Z. Shor r-algorithm; nonlinear/nonsmooth constrained/unconstrained problems

'''Wrappers'''

* [http://www.coin-or.org/NLPAPI/index.html NLPAPI] (GPL?) a generalised wrapper for NLP solvers, including support for LANCELOT.
* [https://projects.coin-or.org/GAMSlinks/ GAMSlinks] (GPL?) a wrapper for [https://projects.coin-or.org/ COIN-OR] solvers that allows them to be called from GAMS. This is interesting as it shows how we could implement set up ASCEND so that it can use GAMS solvers, which adapting FOSS solvers that run under GAMS much easier to adapt for use with ASCEND.
* [http://www.netlib.org/ampl/solvers/lancelot/ AMPL/LANCELOT] a wrapper for running LANCELOT from AMPL. Again, this provides a way for seeing how solvers that have been adapted for use in AMPL might be also be connected to from ASCEND.
* [http://cuter.rl.ac.uk/cuter-www/interfaces.html CUTEr] (GPL-like license) is a wrapper for a wide range of optimisation solvers, and also a testing framework.
* [https://projects.coin-or.org/Osi OSI] (CPL?) wrapper for quite a wide range of LP solvers, from COIN-OR.
* [https://projects.coin-or.org/OS OS] (CPL?) Optimisation Services, a number of interface languages and APIs for communicating between problem 'servers' and solver 'clients', with support for a range of COIN-OR solvers and converters for GAMS/AMPL input files.
* [http://wiki.services.openoffice.org/wiki/Optimization_Solver OpenOffice.org's Solver]
* [http://openopt.org OpenOpt] (BSD) a general purpose optimization framework written in Python and NumPy, capable of automatic differentiation.

'''Unknown:'''

* [http://coool.mines.edu/ COOOL]

Another free list: [http://software.sandia.gov/Acro/html/Main/AcroPackages.html]

There are some more listed in the [ftp://rtfm.mit.edu/pub/usenet/sci.answers/nonlinear-programming-faq nonlinear-programming-faq].

== Free for non-commercial use ==

Trust region

* [http://www.numerical.rl.ac.uk/lancelot/blurb.html LANCELOT] (no redistribution or resale) Trust region method, adapt for bound constraints

Active set

* [http://www-unix.mcs.anl.gov/~more/tron/ TRON] (permission to copy and modify, but only to be used for 'internal research' ([http://plato.asu.edu/ftp/other_software/tron_f90.tar.gz download]) active set method that uses a combination of gradient projections and a preconditioned conjugate gradient method to minimize an objective function. TRON only provides for 'box' constraints and has no support for equality constraints, although it may be possible to add support for that by wrapping TRON around an NLA solver?

Sequential quadratic programming

* [http://plato.la.asu.edu/donlp2.html DONLP2] (dense; free for non-commercial purposes)

== Some proprietary alternatives ==

Generalised reduced gradient method:

* [http://www.conopt.com/ CONOPT] (plus others in certain cases)
* [http://www.sbsi-sol-optimize.com/asp/sol_product_minos.htm MINOS] (uses GRG for linear constraints, else 'sparse SLC algorithm (a projected Lagrangian method, related to Robinson's method)' for nonlinear constraints. Used when gradient evaluation is cheap.
* MS Excel [http://support.microsoft.com/kb/q214115/ Solver].
* GRG2
* LSGRG2
* [http://www.pinterconsulting.com/ LGO] 'Lipschitz Global Optimizer'

Sequential quadratic programming:

* [http://www.sbsi-sol-optimize.com/asp/sol_products_snopt_desc.htm SNOPT] (sparse) Used when gradient evaluation is expensive. 'SNOPT employs a sparse SQP algorithm with limited-memory quasi-Newton approximations to the Hessian of Lagrangian. An augmented Lagrangian merit function promotes convergence from an arbitrary point.'
* [http://www.uni-bayreuth.de/departments/math/~kschittkowski/nlpqlp22.htm NLPQLP]
* [http://www.sbsi-sol-optimize.com/asp/sol_product_npsol.htm NPSOL]
* [http://www.sbsi-sol-optimize.com/asp/sol_lssol105description.htm LSSOL] (dense, 'two-phase (primal) quadratic programming')
* [http://www.princeton.edu/~rvdb/ LOQO] (free 30-day trial) 'LOQO is based on an infeasible, primal-dual, interior-point method applied to a sequence of quadratic approximations to the given problem'
* [http://www.mcs.anl.gov/~leyffer/solvers.html FilterSQP]

Active set method:

* [http://www.sbsi-sol-optimize.com/asp/sol_product_qpopt.htm QPOPT] (dense)

Other methods:

* [http://www.ziena.com/knitro.htm KNITRO] (three methods: interior point direct, interior point conjugate gradient, 'active set')
* [http://www.gams.com/dd/docs/solvers/pathnlp.pdf PATHNLP]. 'PATHNLP solves an NLP by internally constructing the Karush-Kuhn-Tucker (KKT) system of first-order optimality conditions associated with the NLP and solving this system using the PATH solver for complementarity problems'. Supposedly good for convex problems.
* [http://www.mosek.com/products.html MOSEK] (limited version available for download, or free student license) Interior point method plus simplex method.
* [http://www2.am.uni-erlangen.de/~kocvara/pennon/ PENNON] 'penalty method', 'PBM method of Ben-Tal and Zibulevsky'

Global optimisation

* [http://www.andrew.cmu.edu/user/ns1b/baron/baron.html BARON]
* [http://www.ganso.com.au/index.php GANSO]

Methods not yet checked:

* IMSL and NAG software libraries
''More to come''

Mixed integer/nonlinear programs:

* [http://www.gams.com/solvers/solvers.htm#DICOPT DICOPT]: MINLP

See also [[Survey of sparse matrix software]]

[[Category:Development]]
[[Category:Miscellany]]

Survey of optimisation software

2010-05-17T03:01:34Z

WikiSysop: /* Free Open Source Software options */

The following is a survey of optimisation software that was performed as a part of our effort to identify options for a [[Non-proprietary Optimisation]] solver for ASCEND. Feel free to add any that we've missed.

== List of Lists ==

* List of NLP solvers: [http://www.ici.ro/camo/hnp.htm]
* List of unconstrained optimisation solvers: [http://www.ici.ro/camo/huo.htm]
* There ''was'' a nice list at [http://www.scicomp.uni-erlangen.de/SW/opt.html] but the link seems to be broken at the moment.
* 'Decision tree' for optimization software [http://plato.asu.edu/sub/nlores.html]
* Description of different types of optimisation problems: [http://coool.mines.edu/report/node3.html]

== Free Open Source Software options ==

* [https://projects.coin-or.org/Ipopt IPOPT] (LGPL) 'Interior-Point Filter Line-Search Algorithm'. Possibly some problems with scaling of variables (according to RPS). can use a number of free and non-free matrix solvers; the free matrix solver in version 3.3.1 is MUMPS. See also [[IPOPT]] in this wiki.
* [http://trilinos.sandia.gov/packages/moocho/ MOOCHO] (GPL?) reduced sequential quadratic programming (SQP); allows the user to supply their own linear solver.
* [http://www.gnu.org/software/gsl/manual/html_node/Multidimensional-Minimization.html GSL 'multimin'] (GPL) several multidimensional dense-matrix unconstrained optimisation methods including conjugate gradient methods, quasi-newton methods, steepest descent and Nelder-Mead simplex method.
* [http://acts.nersc.gov/opt++/index.html OPT++] (free, includes ''optional'' wrapping of non-free NPSOL). Good but dense matrices only (RPS). Superceded by MOOCHO?
* [http://software.sandia.gov/appspack/version5.0/index.html APPSPACK] (GPL?) 'asynchronous parallel generating set search', derivative-free.
* [http://www.eng.buffalo.edu/Research/MODEL/mdo.test.orig/CONMIN/ CONMIN] ('free' but where from?) 'two-step limited memory quasi Newton like Conjugate Gradient method with Beale restarts'.
* [http://www.cs.sandia.gov/SGOPT/ SGOPT] (LGPL) Evolutionary and pattern-search algorithms
* [http://www.math.ufl.edu/~hager/ OPTPACK] (PD) 'a dual algorithm for constrained optimization'
* [http://www.netlib.org/minpack/ MINPACK] (BSD-like) unconstrained
* [http://www.coin-or.org/Bonmin/ BonMin] (CPL) Part of the COIN-OR suite; a solver for convect MINLP problems.
* [https://projects.coin-or.org/Couenne Couenne] (CPL) Part of the COIN-OR suite; a solver for non-convex MINLP problems.
* [http://www.ime.usp.br/~egbirgin/tango/ ALGENCAN] (GPL) Augmented Lagrangian plus an embedded smooth function box-constraint solver called 'GENCAN'
* [http://www.ime.usp.br/~egbirgin/tango/ SPG] (GPL) for smooth function with convex constraint
* [http://www.gerad.ca/~couturgi/NOMAD/ NOMAD] (GPL) Generalized Pattern Search (GPS) algorithms to solve nonlinear optimization problems
* [http://www-fp.mcs.anl.gov/otc/Tools/LBFGS-B/ LBFGS-B] (PD?) limited-memory quasi-Newton code
* [http://ab-initio.mit.edu/wiki/index.php/NLopt NLopt] (LGPL) wrapper for a few other FOSS codes, but also reportedly has some new implementations of certain algorithms
* [http://www.uni-graz.at/imawww/kuntsevich/solvopt/ SolvOpt] (PD) 'method of exact penalisation', based on N.Z. Shor r-algorithm
* [http://openopt.org/ralg ralg] (BSD) - an implementation of N.Z. Shor r-algorithm; nonlinear/nonsmooth constrained/unconstrained problems

'''Wrappers'''

* [http://www.coin-or.org/NLPAPI/index.html NLPAPI] (GPL?) a generalised wrapper for NLP solvers, including support for LANCELOT.
* [https://projects.coin-or.org/GAMSlinks/ GAMSlinks] (GPL?) a wrapper for [https://projects.coin-or.org/ COIN-OR] solvers that allows them to be called from GAMS. This is interesting as it shows how we could implement set up ASCEND so that it can use GAMS solvers, which adapting FOSS solvers that run under GAMS much easier to adapt for use with ASCEND.
* [http://www.netlib.org/ampl/solvers/lancelot/ AMPL/LANCELOT] a wrapper for running LANCELOT from AMPL. Again, this provides a way for seeing how solvers that have been adapted for use in AMPL might be also be connected to from ASCEND.
* [http://cuter.rl.ac.uk/cuter-www/interfaces.html CUTEr] (GPL-like license) is a wrapper for a wide range of optimisation solvers, and also a testing framework.
* [https://projects.coin-or.org/Osi OSI] (CPL?) wrapper for quite a wide range of LP solvers, from COIN-OR.
* [https://projects.coin-or.org/OS OS<] (CPL?) Optimisation Services, a number of interface languages and APIs for communicating between problem 'servers' and solver 'clients', with support for a range of COIN-OR solvers and converters for GAMS/AMPL input files.
* [http://wiki.services.openoffice.org/wiki/Optimization_Solver OpenOffice.org's Solver]
* [http://openopt.org OpenOpt] (BSD) a general purpose optimization framework written in Python and NumPy, capable of automatic differentiation.

'''Unknown:'''

* [http://coool.mines.edu/ COOOL]

Another free list: [http://software.sandia.gov/Acro/html/Main/AcroPackages.html]

There are some more listed in the [ftp://rtfm.mit.edu/pub/usenet/sci.answers/nonlinear-programming-faq nonlinear-programming-faq].

== Free for non-commercial use ==

Trust region

* [http://www.numerical.rl.ac.uk/lancelot/blurb.html LANCELOT] (no redistribution or resale) Trust region method, adapt for bound constraints

Active set

* [http://www-unix.mcs.anl.gov/~more/tron/ TRON] (permission to copy and modify, but only to be used for 'internal research' ([http://plato.asu.edu/ftp/other_software/tron_f90.tar.gz download]) active set method that uses a combination of gradient projections and a preconditioned conjugate gradient method to minimize an objective function. TRON only provides for 'box' constraints and has no support for equality constraints, although it may be possible to add support for that by wrapping TRON around an NLA solver?

Sequential quadratic programming

* [http://plato.la.asu.edu/donlp2.html DONLP2] (dense; free for non-commercial purposes)

== Some proprietary alternatives ==

Generalised reduced gradient method:

* [http://www.conopt.com/ CONOPT] (plus others in certain cases)
* [http://www.sbsi-sol-optimize.com/asp/sol_product_minos.htm MINOS] (uses GRG for linear constraints, else 'sparse SLC algorithm (a projected Lagrangian method, related to Robinson's method)' for nonlinear constraints. Used when gradient evaluation is cheap.
* MS Excel [http://support.microsoft.com/kb/q214115/ Solver].
* GRG2
* LSGRG2
* [http://www.pinterconsulting.com/ LGO] 'Lipschitz Global Optimizer'

Sequential quadratic programming:

* [http://www.sbsi-sol-optimize.com/asp/sol_products_snopt_desc.htm SNOPT] (sparse) Used when gradient evaluation is expensive. 'SNOPT employs a sparse SQP algorithm with limited-memory quasi-Newton approximations to the Hessian of Lagrangian. An augmented Lagrangian merit function promotes convergence from an arbitrary point.'
* [http://www.uni-bayreuth.de/departments/math/~kschittkowski/nlpqlp22.htm NLPQLP]
* [http://www.sbsi-sol-optimize.com/asp/sol_product_npsol.htm NPSOL]
* [http://www.sbsi-sol-optimize.com/asp/sol_lssol105description.htm LSSOL] (dense, 'two-phase (primal) quadratic programming')
* [http://www.princeton.edu/~rvdb/ LOQO] (free 30-day trial) 'LOQO is based on an infeasible, primal-dual, interior-point method applied to a sequence of quadratic approximations to the given problem'
* [http://www.mcs.anl.gov/~leyffer/solvers.html FilterSQP]

Active set method:

* [http://www.sbsi-sol-optimize.com/asp/sol_product_qpopt.htm QPOPT] (dense)

Other methods:

* [http://www.ziena.com/knitro.htm KNITRO] (three methods: interior point direct, interior point conjugate gradient, 'active set')
* [http://www.gams.com/dd/docs/solvers/pathnlp.pdf PATHNLP]. 'PATHNLP solves an NLP by internally constructing the Karush-Kuhn-Tucker (KKT) system of first-order optimality conditions associated with the NLP and solving this system using the PATH solver for complementarity problems'. Supposedly good for convex problems.
* [http://www.mosek.com/products.html MOSEK] (limited version available for download, or free student license) Interior point method plus simplex method.
* [http://www2.am.uni-erlangen.de/~kocvara/pennon/ PENNON] 'penalty method', 'PBM method of Ben-Tal and Zibulevsky'

Global optimisation

* [http://www.andrew.cmu.edu/user/ns1b/baron/baron.html BARON]
* [http://www.ganso.com.au/index.php GANSO]

Methods not yet checked:

* IMSL and NAG software libraries
''More to come''

Mixed integer/nonlinear programs:

* [http://www.gams.com/solvers/solvers.htm#DICOPT DICOPT]: MINLP

See also [[Survey of sparse matrix software]]

[[Category:Development]]
[[Category:Miscellany]]

Survey of optimisation software

2010-05-17T02:59:57Z

WikiSysop: /* Some proprietary alternatives */

The following is a survey of optimisation software that was performed as a part of our effort to identify options for a [[Non-proprietary Optimisation]] solver for ASCEND. Feel free to add any that we've missed.

== List of Lists ==

* List of NLP solvers: [http://www.ici.ro/camo/hnp.htm]
* List of unconstrained optimisation solvers: [http://www.ici.ro/camo/huo.htm]
* There ''was'' a nice list at [http://www.scicomp.uni-erlangen.de/SW/opt.html] but the link seems to be broken at the moment.
* 'Decision tree' for optimization software [http://plato.asu.edu/sub/nlores.html]
* Description of different types of optimisation problems: [http://coool.mines.edu/report/node3.html]

== Free Open Source Software options ==

* <a href="https://projects.coin-or.org/Ipopt" class="external text" title="https://projects.coin-or.org/Ipopt" rel="nofollow">IPOPT</a> (LGPL) 'Interior-Point Filter Line-Search Algorithm'. Possibly some problems with scaling of variables (according to RPS). can use a number of free and non-free matrix solvers; the free matrix solver in version 3.3.1 is MUMPS. See also [[IPOPT]] in this wiki.
* [http://trilinos.sandia.gov/packages/moocho/ MOOCHO] (GPL?) reduced sequential quadratic programming (SQP); allows the user to supply their own linear solver.
* [http://www.gnu.org/software/gsl/manual/html_node/Multidimensional-Minimization.html GSL 'multimin'] (GPL) several multidimensional dense-matrix unconstrained optimisation methods including conjugate gradient methods, quasi-newton methods, steepest descent and Nelder-Mead simplex method.
* [http://acts.nersc.gov/opt++/index.html OPT++] (free, includes ''optional'' wrapping of non-free NPSOL). Good but dense matrices only (RPS). Superceded by MOOCHO?
* [http://software.sandia.gov/appspack/version5.0/index.html APPSPACK] (GPL?) 'asynchronous parallel generating set search', derivative-free.
* [http://www.eng.buffalo.edu/Research/MODEL/mdo.test.orig/CONMIN/ CONMIN] ('free' but where from?) 'two-step limited memory quasi Newton like Conjugate Gradient method with Beale restarts'.
* [http://www.cs.sandia.gov/SGOPT/ SGOPT] (LGPL) Evolutionary and pattern-search algorithms
* [http://www.math.ufl.edu/~hager/ OPTPACK] (PD) 'a dual algorithm for constrained optimization'
* [http://www.netlib.org/minpack/ MINPACK] (BSD-like) unconstrained
* [http://www.coin-or.org/Bonmin/ BonMin] (CPL) Part of the COIN-OR suite; a solver for convect MINLP problems.
* <a href="https://projects.coin-or.org/Couenne" class="external text" title="https://projects.coin-or.org/Couenne" rel="nofollow">Couenne</a> (CPL) Part of the COIN-OR suite; a solver for non-convex MINLP problems.
* [http://www.ime.usp.br/~egbirgin/tango/ ALGENCAN] (GPL) Augmented Lagrangian plus an embedded smooth function box-constraint solver called 'GENCAN'
* [http://www.ime.usp.br/~egbirgin/tango/ SPG] (GPL) for smooth function with convex constraint
* [http://www.gerad.ca/~couturgi/NOMAD/ NOMAD] (GPL) Generalized Pattern Search (GPS) algorithms to solve nonlinear optimization problems
* [http://www-fp.mcs.anl.gov/otc/Tools/LBFGS-B/ LBFGS-B] (PD?) limited-memory quasi-Newton code
* [http://ab-initio.mit.edu/wiki/index.php/NLopt NLopt] (LGPL) wrapper for a few other FOSS codes, but also reportedly has some new implementations of certain algorithms
* [http://www.uni-graz.at/imawww/kuntsevich/solvopt/ SolvOpt] (PD) 'method of exact penalisation', based on N.Z. Shor r-algorithm
* [http://openopt.org/ralg ralg] (BSD) - an implementation of N.Z. Shor r-algorithm; nonlinear/nonsmooth constrained/unconstrained problems

'''Wrappers'''

* [http://www.coin-or.org/NLPAPI/index.html NLPAPI] (GPL?) a generalised wrapper for NLP solvers, including support for LANCELOT.
* <a href="https://projects.coin-or.org/GAMSlinks/" class="external text" title="https://projects.coin-or.org/GAMSlinks/" rel="nofollow">GAMSlinks</a> (GPL?) a wrapper for <a href="https://projects.coin-or.org/" class="external text" title="https://projects.coin-or.org/" rel="nofollow">COIN-OR</a> solvers that allows them to be called from GAMS. This is interesting as it shows how we could implement set up ASCEND so that it can use GAMS solvers, which adapting FOSS solvers that run under GAMS much easier to adapt for use with ASCEND.
* [http://www.netlib.org/ampl/solvers/lancelot/ AMPL/LANCELOT] a wrapper for running LANCELOT from AMPL. Again, this provides a way for seeing how solvers that have been adapted for use in AMPL might be also be connected to from ASCEND.
* [http://cuter.rl.ac.uk/cuter-www/interfaces.html CUTEr] (GPL-like license) is a wrapper for a wide range of optimisation solvers, and also a testing framework.
* <a href="https://projects.coin-or.org/Osi" class="external text" title="https://projects.coin-or.org/Osi" rel="nofollow">OSI</a> (CPL?) wrapper for quite a wide range of LP solvers, from COIN-OR.
* <a href="https://projects.coin-or.org/OS" class="external text" title="https://projects.coin-or.org/OS" rel="nofollow">OS</a> (CPL?) Optimisation Services, a number of interface languages and APIs for communicating between problem 'servers' and solver 'clients', with support for a range of COIN-OR solvers and converters for GAMS/AMPL input files.
* [http://wiki.services.openoffice.org/wiki/Optimization_Solver OpenOffice.org's Solver]
* [http://openopt.org OpenOpt] (BSD) a general purpose optimization framework written in Python and NumPy, capable of automatic differentiation.

'''Unknown:'''

* [http://coool.mines.edu/ COOOL]

Another free list: [http://software.sandia.gov/Acro/html/Main/AcroPackages.html]

There are some more listed in the <a href="ftp://rtfm.mit.edu/pub/usenet/sci.answers/nonlinear-programming-faq" class="external text" title="ftp://rtfm.mit.edu/pub/usenet/sci.answers/nonlinear-programming-faq" rel="nofollow">nonlinear-programming-faq</a>.

== Free for non-commercial use ==

Trust region

* [http://www.numerical.rl.ac.uk/lancelot/blurb.html LANCELOT] (no redistribution or resale) Trust region method, adapt for bound constraints

Active set

* [http://www-unix.mcs.anl.gov/~more/tron/ TRON] (permission to copy and modify, but only to be used for 'internal research' ([http://plato.asu.edu/ftp/other_software/tron_f90.tar.gz download]) active set method that uses a combination of gradient projections and a preconditioned conjugate gradient method to minimize an objective function. TRON only provides for 'box' constraints and has no support for equality constraints, although it may be possible to add support for that by wrapping TRON around an NLA solver?

Sequential quadratic programming

* [http://plato.la.asu.edu/donlp2.html DONLP2] (dense; free for non-commercial purposes)

== Some proprietary alternatives ==

Generalised reduced gradient method:

* [http://www.conopt.com/ CONOPT] (plus others in certain cases)
* [http://www.sbsi-sol-optimize.com/asp/sol_product_minos.htm MINOS] (uses GRG for linear constraints, else 'sparse SLC algorithm (a projected Lagrangian method, related to Robinson's method)' for nonlinear constraints. Used when gradient evaluation is cheap.
* MS Excel [http://support.microsoft.com/kb/q214115/ Solver].
* GRG2
* LSGRG2
* [http://www.pinterconsulting.com/ LGO] 'Lipschitz Global Optimizer'

Sequential quadratic programming:

* [http://www.sbsi-sol-optimize.com/asp/sol_products_snopt_desc.htm SNOPT] (sparse) Used when gradient evaluation is expensive. 'SNOPT employs a sparse SQP algorithm with limited-memory quasi-Newton approximations to the Hessian of Lagrangian. An augmented Lagrangian merit function promotes convergence from an arbitrary point.'
* [http://www.uni-bayreuth.de/departments/math/~kschittkowski/nlpqlp22.htm NLPQLP]
* [http://www.sbsi-sol-optimize.com/asp/sol_product_npsol.htm NPSOL]
* [http://www.sbsi-sol-optimize.com/asp/sol_lssol105description.htm LSSOL] (dense, 'two-phase (primal) quadratic programming')
* [http://www.princeton.edu/~rvdb/ LOQO] (free 30-day trial) 'LOQO is based on an infeasible, primal-dual, interior-point method applied to a sequence of quadratic approximations to the given problem'
* [http://www.mcs.anl.gov/~leyffer/solvers.html FilterSQP]

Active set method:

* [http://www.sbsi-sol-optimize.com/asp/sol_product_qpopt.htm QPOPT] (dense)

Other methods:

* [http://www.ziena.com/knitro.htm KNITRO] (three methods: interior point direct, interior point conjugate gradient, 'active set')
* [http://www.gams.com/dd/docs/solvers/pathnlp.pdf PATHNLP]. 'PATHNLP solves an NLP by internally constructing the Karush-Kuhn-Tucker (KKT) system of first-order optimality conditions associated with the NLP and solving this system using the PATH solver for complementarity problems'. Supposedly good for convex problems.
* [http://www.mosek.com/products.html MOSEK] (limited version available for download, or free student license) Interior point method plus simplex method.
* [http://www2.am.uni-erlangen.de/~kocvara/pennon/ PENNON] 'penalty method', 'PBM method of Ben-Tal and Zibulevsky'

Global optimisation

* [http://www.andrew.cmu.edu/user/ns1b/baron/baron.html BARON]
* [http://www.ganso.com.au/index.php GANSO]

Methods not yet checked:

* IMSL and NAG software libraries
''More to come''

Mixed integer/nonlinear programs:

* [http://www.gams.com/solvers/solvers.htm#DICOPT DICOPT]: MINLP

See also [[Survey of sparse matrix software]]

[[Category:Development]]
[[Category:Miscellany]]

Survey of optimisation software

2010-05-17T02:59:42Z

WikiSysop:

The following is a survey of optimisation software that was performed as a part of our effort to identify options for a [[Non-proprietary Optimisation]] solver for ASCEND. Feel free to add any that we've missed.

== List of Lists ==

* List of NLP solvers: [http://www.ici.ro/camo/hnp.htm]
* List of unconstrained optimisation solvers: [http://www.ici.ro/camo/huo.htm]
* There ''was'' a nice list at [http://www.scicomp.uni-erlangen.de/SW/opt.html] but the link seems to be broken at the moment.
* 'Decision tree' for optimization software [http://plato.asu.edu/sub/nlores.html]
* Description of different types of optimisation problems: [http://coool.mines.edu/report/node3.html]

== Free Open Source Software options ==

* <a href="https://projects.coin-or.org/Ipopt" class="external text" title="https://projects.coin-or.org/Ipopt" rel="nofollow">IPOPT</a> (LGPL) 'Interior-Point Filter Line-Search Algorithm'. Possibly some problems with scaling of variables (according to RPS). can use a number of free and non-free matrix solvers; the free matrix solver in version 3.3.1 is MUMPS. See also [[IPOPT]] in this wiki.
* [http://trilinos.sandia.gov/packages/moocho/ MOOCHO] (GPL?) reduced sequential quadratic programming (SQP); allows the user to supply their own linear solver.
* [http://www.gnu.org/software/gsl/manual/html_node/Multidimensional-Minimization.html GSL 'multimin'] (GPL) several multidimensional dense-matrix unconstrained optimisation methods including conjugate gradient methods, quasi-newton methods, steepest descent and Nelder-Mead simplex method.
* [http://acts.nersc.gov/opt++/index.html OPT++] (free, includes ''optional'' wrapping of non-free NPSOL). Good but dense matrices only (RPS). Superceded by MOOCHO?
* [http://software.sandia.gov/appspack/version5.0/index.html APPSPACK] (GPL?) 'asynchronous parallel generating set search', derivative-free.
* [http://www.eng.buffalo.edu/Research/MODEL/mdo.test.orig/CONMIN/ CONMIN] ('free' but where from?) 'two-step limited memory quasi Newton like Conjugate Gradient method with Beale restarts'.
* [http://www.cs.sandia.gov/SGOPT/ SGOPT] (LGPL) Evolutionary and pattern-search algorithms
* [http://www.math.ufl.edu/~hager/ OPTPACK] (PD) 'a dual algorithm for constrained optimization'
* [http://www.netlib.org/minpack/ MINPACK] (BSD-like) unconstrained
* [http://www.coin-or.org/Bonmin/ BonMin] (CPL) Part of the COIN-OR suite; a solver for convect MINLP problems.
* <a href="https://projects.coin-or.org/Couenne" class="external text" title="https://projects.coin-or.org/Couenne" rel="nofollow">Couenne</a> (CPL) Part of the COIN-OR suite; a solver for non-convex MINLP problems.
* [http://www.ime.usp.br/~egbirgin/tango/ ALGENCAN] (GPL) Augmented Lagrangian plus an embedded smooth function box-constraint solver called 'GENCAN'
* [http://www.ime.usp.br/~egbirgin/tango/ SPG] (GPL) for smooth function with convex constraint
* [http://www.gerad.ca/~couturgi/NOMAD/ NOMAD] (GPL) Generalized Pattern Search (GPS) algorithms to solve nonlinear optimization problems
* [http://www-fp.mcs.anl.gov/otc/Tools/LBFGS-B/ LBFGS-B] (PD?) limited-memory quasi-Newton code
* [http://ab-initio.mit.edu/wiki/index.php/NLopt NLopt] (LGPL) wrapper for a few other FOSS codes, but also reportedly has some new implementations of certain algorithms
* [http://www.uni-graz.at/imawww/kuntsevich/solvopt/ SolvOpt] (PD) 'method of exact penalisation', based on N.Z. Shor r-algorithm
* [http://openopt.org/ralg ralg] (BSD) - an implementation of N.Z. Shor r-algorithm; nonlinear/nonsmooth constrained/unconstrained problems

'''Wrappers'''

* [http://www.coin-or.org/NLPAPI/index.html NLPAPI] (GPL?) a generalised wrapper for NLP solvers, including support for LANCELOT.
* <a href="https://projects.coin-or.org/GAMSlinks/" class="external text" title="https://projects.coin-or.org/GAMSlinks/" rel="nofollow">GAMSlinks</a> (GPL?) a wrapper for <a href="https://projects.coin-or.org/" class="external text" title="https://projects.coin-or.org/" rel="nofollow">COIN-OR</a> solvers that allows them to be called from GAMS. This is interesting as it shows how we could implement set up ASCEND so that it can use GAMS solvers, which adapting FOSS solvers that run under GAMS much easier to adapt for use with ASCEND.
* [http://www.netlib.org/ampl/solvers/lancelot/ AMPL/LANCELOT] a wrapper for running LANCELOT from AMPL. Again, this provides a way for seeing how solvers that have been adapted for use in AMPL might be also be connected to from ASCEND.
* [http://cuter.rl.ac.uk/cuter-www/interfaces.html CUTEr] (GPL-like license) is a wrapper for a wide range of optimisation solvers, and also a testing framework.
* <a href="https://projects.coin-or.org/Osi" class="external text" title="https://projects.coin-or.org/Osi" rel="nofollow">OSI</a> (CPL?) wrapper for quite a wide range of LP solvers, from COIN-OR.
* <a href="https://projects.coin-or.org/OS" class="external text" title="https://projects.coin-or.org/OS" rel="nofollow">OS</a> (CPL?) Optimisation Services, a number of interface languages and APIs for communicating between problem 'servers' and solver 'clients', with support for a range of COIN-OR solvers and converters for GAMS/AMPL input files.
* [http://wiki.services.openoffice.org/wiki/Optimization_Solver OpenOffice.org's Solver]
* [http://openopt.org OpenOpt] (BSD) a general purpose optimization framework written in Python and NumPy, capable of automatic differentiation.

'''Unknown:'''

* [http://coool.mines.edu/ COOOL]

Another free list: [http://software.sandia.gov/Acro/html/Main/AcroPackages.html]

There are some more listed in the <a href="ftp://rtfm.mit.edu/pub/usenet/sci.answers/nonlinear-programming-faq" class="external text" title="ftp://rtfm.mit.edu/pub/usenet/sci.answers/nonlinear-programming-faq" rel="nofollow">nonlinear-programming-faq</a>.

== Free for non-commercial use ==

Trust region

* [http://www.numerical.rl.ac.uk/lancelot/blurb.html LANCELOT] (no redistribution or resale) Trust region method, adapt for bound constraints

Active set

* [http://www-unix.mcs.anl.gov/~more/tron/ TRON] (permission to copy and modify, but only to be used for 'internal research' ([http://plato.asu.edu/ftp/other_software/tron_f90.tar.gz download]) active set method that uses a combination of gradient projections and a preconditioned conjugate gradient method to minimize an objective function. TRON only provides for 'box' constraints and has no support for equality constraints, although it may be possible to add support for that by wrapping TRON around an NLA solver?

Sequential quadratic programming

* [http://plato.la.asu.edu/donlp2.html DONLP2] (dense; free for non-commercial purposes)

== Some proprietary alternatives ==

Generalised reduced gradient method:

* [http://www.conopt.com/ CONOPT] (plus others in certain cases)
* [http://www.sbsi-sol-optimize.com/asp/sol_product_minos.htm MINOS] (uses GRG for linear constraints, else 'sparse SLC algorithm (a projected Lagrangian method, related to Robinson's method)' for nonlinear constraints. Used when gradient evaluation is cheap.
* MS Excel [http://support.microsoft.com/kb/q214115/ Solver].
* GRG2
* LSGRG2
* [http://www.pinterconsulting.com/ LGO] 'Lipschitz Global Optimizer'

Sequential quadratic programming:

* [http://www.sbsi-sol-optimize.com/asp/sol_products_snopt_desc.htm SNOPT] (sparse) Used when gradient evaluation is expensive. 'SNOPT employs a sparse SQP algorithm with limited-memory quasi-Newton approximations to the Hessian of Lagrangian. An augmented Lagrangian merit function promotes convergence from an arbitrary point.'
* [http://www.uni-bayreuth.de/departments/math/~kschittkowski/nlpqlp22.htm NLPQLP]
* [http://www.sbsi-sol-optimize.com/asp/sol_product_npsol.htm NPSOL]
* [http://www.sbsi-sol-optimize.com/asp/sol_lssol105description.htm LSSOL] (dense, 'two-phase (primal) quadratic programming')
* [http://www.princeton.edu/~rvdb/ LOQO] (free 30-day trial) 'LOQO is based on an infeasible, primal-dual, interior-point method applied to a sequence of quadratic approximations to the given problem'
* [http://www.mcs.anl.gov/~leyffer/solvers.html FilterSQP]

Active set method:

* [http://www.sbsi-sol-optimize.com/asp/sol_product_qpopt.htm QPOPT] (dense)

Other methods:

* [http://www.ziena.com/knitro.htm KNITRO] (three methods: interior point direct, interior point conjugate gradient, 'active set')
* [http://www.gams.com/dd/docs/solvers/pathnlp.pdf PATHNLP]. 'PATHNLP solves an NLP by internally constructing the Karush-Kuhn-Tucker (KKT) system of first-order optimality conditions associated with the NLP and solving this system using the PATH solver for complementarity problems'. Supposedly good for convex problems.
* [http://www.mosek.com/products.html MOSEK] (limited version available for download, or free student license) Interior point method plus simplex method.
* [http://www2.am.uni-erlangen.de/~kocvara/pennon/ PENNON] 'penalty method', 'PBM method of Ben-Tal and Zibulevsky'

Global optimisation

* [http://www.andrew.cmu.edu/user/ns1b/baron/baron.html BARON]
* [http://www.ganso.com.au/index.php GANSO]

Methods not yet checked:

* IMSL and NAG software libraries
''More to come''

Mixed integer/nonlinear programs:

* [http://www.gams.com/solvers/solvers.htm#DICOPT DICOPT]: MINLP

See also [[Survey of sparse matrix software]]

[[Category:Development]]

Scripting ASCEND using Python

2010-05-17T02:58:36Z

WikiSysop:

It's possible to write scripts that 'drive' ASCEND, using the [http://en.wikipedia.org/wiki/Python_%28programming_language%29 Python] language. These scripts can be used for any task you can think of, with the ASCEND engine providing the core capability of loading a system of equations, getting it ready to solve, and then solving it. For example:

* you have a model and you want to run a large number of parameter studies on it. You can write a Python script to loop through different cases and solve the model for each one and extract the results and put them into a table.
* you want to plot curves for thermodynamic property data, but the built-in plotting capability of ASCEND doesn't seem right for the job
* you want to incorporate an ASCEND model into a program with a custom GUI to make it easier for non-technical users to use it
* you want to write a test suite to check that a model still does what it did when you first write it, and you want to run that test suite automatically every night.

As well as the current suppport for Python scripting of ASCEND, it's also possible to write ASCEND scripts using Tcl/Tk. See [[Category:Documentation|the user's manual]] for more information on that.

There are two different ways of accessing the Python API for ASCEND. The first way is the more natural one, which is to simply write a standalone Python script that '''wraps''' the ASCEND engine and makes it do things. The second way is via the [[ExtPy]] mechanism, which lets you write fragments of Python that can be run '''embedded''' within the [[METHODS]] interface in the PyGTK GUI. The first is better for quick hacks, the second is better for providing reusable functionality, although it still represents code at a somewhat experimental stage.

Currently, the best place to find examples of what can be done with the ASCEND Python API is in the code of the file {{src|test.py}} from the code repository. There is not yet any good documentation for the Python API, unfortunately.

== Example of a standalone Python script with ASCEND ==

Here is an example of a simple script that loads a model (namely {{src|models/johnpye/testlog10.a4c}}) and solves it, then runs the 'self_test' method on the model, then prints out the value of a variable from the model.

<source lang="py">#!/usr/bin/env python
# file 'example.py':

import ascpy
L = ascpy.Library()

L.load("johnpye/testlog10.a4c")

T = L.findType("testlog10")
M = T.getSimulation('sim')

M.solve(ascpy.Solver("QRSlv"),ascpy.SolverReporter())
M.run(T.getMethod('self_test'))

print "After solving, z =",float(M.z)</source>

This script can be run using the command

<source lang="sh">PYTHONPATH=~/ascend/pygtk python example.py</source>

As well as stacks of debug output, this also finally outputs:

<pre>
-----------------solve----------------
pygtk/simulation.cpp:804 (solve): Elapsed time: 0.000 (solver completed)
Converged
pygtk/simulation.cpp:889 (processVarStatus): There are 2 blocks
EMPTY METHOD CREATED
pygtk/simulation.cpp:214 (run): Running method self_test...
base/generic/utilities/error.c:161 (error_reporter_tree_end): TREE END
SUCCESS: /home/john/ascend/models/johnpye/testlog10.a4c:24:ASSERT: Assertion OK
SUCCESS: /home/john/ascend/models/johnpye/testlog10.a4c:25:ASSERT: Assertion OK
SUCCESS: /home/john/ascend/models/johnpye/testlog10.a4c:26:ASSERT: Assertion OK
base/generic/utilities/error.c:308 (va_error_reporter): DONE WRITING TREE
SUCCESS: Method 'self_test' returned 'all_ok' and output no errors.

After solving, z = 2.30258509299
</pre>

With care, one can set up the model then repeatedly solve it for different variable values, etc.

== Example of a script embedded within an ASCEND model ==

See [[ExtPy]].

[[Category:Documentation]]
[[Category:Examples]]

Scripting ASCEND using Python

2010-05-17T02:58:24Z

WikiSysop: /* Example of a standalone Python script with ASCEND */

Scripting ASCEND using Python

2010-05-17T02:58:10Z

WikiSysop: /* Example of a standalone Python script with ASCEND */

ASCEND overview

2010-05-17T02:57:40Z

WikiSysop:

{{missingimages}}

ASCEND is a system for '''solving systems of equations''', aimed at engineers and scientists. It allows you to '''build up complex models''' as as systems constructed from simpler '''sub-models'''. Using ASCEND it is simple to '''play around''' with your model, examine its behaviour, and work out how it can best be solved. You can '''easily change which variables are fixed''' and which are to be solved, and you can examine the way in which the model is being solved.

After looking through this brief introduction to what ASCEND is all about, you might want to look at the [[ASCEND history]], a more detailed list of [[ASCEND capabilities]], see some [[worked examples]], find out about [[ASCEND_Users_and_Friends|the developers]] or look at more detailed [[Category:Documentation|documentation]].

== Example of a simple model in ASCEND ==

In ASCEND, models are written in a special-purpose modelling language that combines declarative ''variables'' and ''equations'' with procedural ''methods''. The following simple method calculates the mass of water in a tank:

<source lang="a4c">REQUIRE "atoms.a4l";

MODEL tank;
V IS_A volume;
A IS_A area;

h IS_A distance;
d IS_A distance;
area_eqn: A = 1{PI} * d^2 / 4.;

vol_eqn: V = A * h;
rho IS_A mass_density;

m IS_A mass;
mass_eqn: m = rho*V;

METHODS
METHOD on_load;
FIX d, h, rho;

d := 50 {cm};
h := 90 {cm};

rho := 1000 {kg/m^3};
END on_load;
END tank;</source>

This model declares variables and equations in the 'main' part of the model. Then, in a method called 'on_load', the model specifies that the variables <tt>d</tt>, <tt>h</tt> and <tt>rho</tt> will be 'fixed', and provides their values.

This model can be loaded into ASCEND, usually just by double-clicking the file, then solved by hitting the 'solve' button, with the following result:

[[Image:simple-tank-example.png]]

This is a very simple model: there is much more that ASCEND can do. For example, '''without editing the above model file''', one can use the GUI to 'fix' the volume and diameter of the tank and solve instead for the height, with just a couple of clicks, then resolve for a new tank volume of 200 L:

[[Image:simple-tank2.png]]

For models like this, ASCEND can quickly show you how it's solving the equation, using a simple graph representation:

[[Image:solve-order.png]]

Simple models like this can be useful and quite efficient ways to inspect the behaviour of simple systems of equations. They can also be useful as quick 'calculators': they can be loaded, the known variables typed in, and the solved results quickly seen.

ASCEND provides a way to keep tables of 'observed' values and plot relationships between variables:

[[Image:observer.png]][[Image:observer-plot.png]]

Note that ASCEND is dealing with [[units of measurement]] clearly and transparently. In ASCEND you never have to worry about 'getting the units right' because it understands how to convert between different units like in, ft, cm, m, km for length and L, m³ etc for volume.

To learn more about the ASCEND modelling language and how it can be used to build up models, see the [[Thin Walled Tank]] tutorial.

== More complex models ==

Simple models like this are useful, but serious problems, especially in process engineering and mechanical engineering often involve more complex interactions, often with multiple subsystems, interconnected parts, and so on. In this case, ASCEND provides a number of [[object-oriented modelling]] capabilities, allowing more complicated models to be declared, such as this simple steam power station (Rankine cycle) simulation:

<source lang="a4c">REQUIRE "johnpye/rankine.a4c";
MODEL power_station;

(* sub-models *)
BO IS_A boiler_simple;
TU IS_A turbine_simple;

CO IS_A condenser_simple;
PU IS_A pump_simple;

(* variable 'alias' for convenience *)

mdot ALIASES TU.mdot;

(* connections *)
BO.outlet, TU.inlet ARE_THE_SAME;

TU.outlet, CO.inlet ARE_THE_SAME;
CO.outlet, PU.inlet ARE_THE_SAME;

PU.outlet, BO.inlet ARE_THE_SAME;

(* overall cycle efficiency *)
eta IS_A fraction;

eta * (BO.Qdot_fuel - PU.Wdot) = TU.Wdot;

METHODS
METHOD specify;
RUN ClearAll;
FIX PU.outlet.p, BO.outlet.T, PU.inlet.p, PU.inlet.h, TU.eta, PU.eta, BO.eta, mdot;

END specify;
METHOD values;
mdot := 900 {t/d};

PU.outlet.p := 2000 {psi};
BO.outlet.T := 1460 {R}; BO.outlet.h := 3400 {kJ/kg};

PU.inlet.p := 1 {psi}; PU.inlet.h := 69.73 {btu/lbm};

TU.eta := 1.0; PU.eta := 1.0; BO.eta := 1.0;

END values;
METHOD on_load;
RUN specify;
RUN values;

END on_load;
END power_station;</source>

This model makes use of several sub-parts such as 'pump_simple' and so on, which are defined in another file called 'rankine.a4c' pointed to via the [[REQUIRE]] statement. More documentation [[Category:Syntax|about the syntax]] is available.

Using this style of modular model, it is possible to build and test simple component models, then 'wire them up' into more complex models. This is something that is very difficult to do with standard spreadsheet models as commonly used by engineers. With a library of standard component models at your disposal, you can get working sooner on the complex problems which you have before you.

See [[Object-oriented modelling]] for a summary of language features that help in writing more complex models. You might also be interested in our thoughts about [[Modelling with Spreadsheets]].

== Solvers and integrators ==

The basic engineering calculation being represented in the above examples is a simple "solve for 'x'" type of problem, for which ASCEND uses its [[QRSlv]] solver. For these problems ASCEND orders the equations, then uses [http://en.wikipedia.org/wiki/Newton%27s_method Newton's method] to iteratively solve any sets of simultaneous equations present in the system. However not all engineering problems are like this. Other types of problems can also be solved using ASCEND:

* [[Optimisation|Optimisation problems]], where an objective value must be minimised by varying a set of input variables (see [[CONOPT]], [[IPOPT]])
* [[ODE]] and [[DAE]] problems, where the behaviour of a time-varying system is to be studied (see [[LSODE]], [[IDA]])
* [[Conditional_modelling|Conditional models]], where the applicable equations depend on the value or values of other variables in the model (see [[CMSlv]])

The ASCEND GUI allows you to load a model then select a suitable 'solver' or 'integrator' according to the type of problem that you have. Several solvers are already included with ASCEND, and the API allows you to write new solvers without having to dig into the innards of ASCEND.

ASCEND can show you the model structure as 'viewed' by the solver. For example, using [[QRSlv]], the simple Rankine-cycle model has the following lower-triangular [[incidence matrix]] structure, which indicates that no iterative solving is needed:

[[Image:rankine-incidence.png]]

See [[Solvers]] and [[Dynamic modelling]] for more information.

== Thermodynamics ==

An area where process engineers often run into difficulty with modelling is in incorporating the thermodynamic properties of fluids in their models. ASCEND provides some simple thermodynamics capabilities, which have proven sufficient for modelling distillation and flash problems in chemical engineering, and also integrates with high-accuracy IAPWS-IF97 steam tables for use in power engineering applications.

See [[Thermodynamics with ASCEND]], [[FPROPS]] and [[Steam properties]] for more information.

== Extending ASCEND ==

ASCEND can be extended in a number of ways, using [[external libraries]]. These are pieces of code that ASCEND loads on request. They can be:

* [[External Methods]], doing procedural stuff to models
* [[external relations]], adding new equations to the model, such as complex thermodynamic property relationships
* [[External Solvers]], that solve a model, according to the programmer's definition of 'solve' :-)
* [[external Integrators]], that integrate a model (ie solve for the dynamic response of a system; solve an inital value problem)

External libraries are normally written in C/C++, but we have implemented support for also writing external methods using Python.

== Scripting and automation ==

ASCEND exposes its user interface at several different levels: C, C++ and Python. Usefully, this means that if you have a more complicated modelling problem than can be solved with the ASCEND GUI, you can write a Python script that loads your model and solves it in various ways: effectively you can 'drive' ASCEND however you want, automatically.

See [[Scripting ASCEND using Python]].

== Development of ASCEND ==

ASCEND does enough things to be genuinely useful for engineers, students and scientists, and has an active user group. It was first written around 1978, and has been through several re-writes over that time. Its 'compiler' (which converts the input file into a tree structure containing variables, submodels, and equations) as well as its solvers have been the subject of several PhDs and many features in ASCEND have since been incorporated into commercial simulation programs. Development of ASCEND continues in exciting new directions however. We are working on adding new solvers as well as improving ASCEND's support for solving ODEs and DAEs.

If you are interested in contributing to ASCEND, please see our [[Development Activities]] page and also our list of [[Student Projects]]. We have been accepted to participate in the the 2009Google Summer of Code, so you might even be able to get paid!

[[Category:Documentation]]

MediaWiki:Sidebar

2010-05-17T01:56:23Z

WikiSysop:

MediaWiki:Sidebar

2010-05-17T01:55:56Z

WikiSysop:

MediaWiki:Sidebar

2010-05-17T01:55:31Z

WikiSysop:

John Pye

2010-05-14T07:02:54Z

WikiSysop: Redirected page to User:Jpye

#REDIRECT [[User:Jpye]]

Controlling the solvers from within METHODS

2010-05-14T07:02:39Z

WikiSysop:

{{task}}
The following new proposed syntax has been introduced into the ASCEND language in a developmental branch called slvreq, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/slvreq.h <font color="orange">slvreq</font>:ascend/compiler/slvreq.h].

Support is added for three new statements relating to 'solver requests' in the ASCEND language:

* '''SOLVER''' to specify the solver that should be used.
* '''OPTION''' to specify values for options to be used during solving.
* '''SOLVE''' to actually trigger the user interface to go ahead and solve the MODEL.
<source lang="a4c">MODEL mymodel;
x,y IS_A solver_var;

y = x^2 - x*4 + 4;

METHODS;
METHOD on_load;
FIX y;
y := 0;

SOLVER QRSlv;
OPTION convopt 'RELNOM_SCALE';
SOLVE;
END on_load;

END mymodel;</source>

== Syntax ==
<pre>
SOLVER solvername;
OPTION optionname valuexpression;
SOLVE;
</pre>

It is proposed to additionally set the syntax for solving particular instances, perhaps as

<pre>
SOLVER solvername WITH myinstance
</pre>

or else perhaps as

<pre>
SOLVE myinstance
</pre>

Both of these have implications for the GUI layer and how it organises itself.

==Motivation==

Up until now, the ASCEND language has been carefully designed to avoid polluting the model description with anything relating to actually ''solving'' models; solving was left as something that had to be externally directed, either by .a4s scripts, Python scripts, GUI clicks, or low-level C or C++ code. This has been frequently frustrating when using the PyGTK GUI, because that GUI promotes the idea of being able to just load a model and immediately solve it.

However, many models won't just solve with a simple click of the 'solve' button. Some models need specific solvers to be selected first, and other models will only solve if suitable values of the solver parameters are defined. Neither of these things can be done from within the modelling language, so the result is that the write-test-debug loop for model-making has required the user to either do a lot of spurious clicking to set options each time, or else to write a script to 'drive' ASCEND with the correct settings. Neither of these are particularly user-friendly; [[John Pye]] thinks it should be possible for the user to do 'everything they want' from within a single modelling file.

[[Ben Allan]] has pointed out that such a goal (doing 'everything you want' from within an .a4c file) is unreasonable, because the syntax available within [[METHOD|METHODs]] is too limited to allow anything very sophisticated, and we don't want to develop a full-blown language there. That's a fair point, but the addition of these commands is seen as being so advantageous to user experience that John Pye thought it was worth attempting, regardless.

== Implementation ==

Implementation of this was complicated, because of the deliberate separation of concerns in ASCEND. We have the '''instance tree''' which is manipulated by [[METHOD|METHODs]], then we have a '''slv_system_t''' which is built (by '''system_build'''), and then a '''solver''' essentially just visits that slv_system_t object in order to solve the model. The solver and its associated parameters exist outside the instance tree, making it hard for a METHOD, which works within the instance tree, to access those things.

A new pointer was added to the <tt>SimulationInstance</tt> object, called <tt>slvreq_hooks</tt>, allowing an ASCEND 'driver' (GUI, command-line interface, test suite, etc) to provide hook functions (via a call to <tt>slvreq_assign_hooks</tt>) to which the different SOLVER, OPTION and SOLVE commands could be passed. What those commands then do is left entirely up to the 'driver'.

Whenever the SOLVER command is encountered, it eventually finds its way to a call to <tt>slvreq_set_solver</tt>. This function locates the slvreq_hooks object in the SimulationInstance, and then, if available, runs the <tt>set_solver_fn</tt> hook function (hopefully) earlier provided by the 'driver'.

The OPTION allows an expression to be provided as its argument. This expression is first evaluated, returning a 'value_t' structure. This value is then passed to <tt>slvreq_set_option</tt>, which then runs the <tt>set_option_fn</tt> hook function earlier assigned, if available.

When the SOLVE command is executed, it calls <tt>slvreq_do_solve</tt> and then <tt>do_solve_fn</tt>.

There is currently no support for solving any MODEL other than that returned from </tt>GetSimulationRoot</tt>. Support for this seems to be a little difficult to design.

As mentioned above, how these functions work exactly is up to the 'driver' to define. Some standard error codes are defined, so that the <tt>Initialize</tt> function in [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/initialize.c <font color="orange">slvreq</font>:ascend/compiler/initialize.c] is able to make sensible error messages for the user. But otherwise, the 'driver' gets to decide.

In order to allow the 'driver' to store implementation-dependent data along with the <tt>slvreq_hooks</tt>, a <tt>user_data</tt> pointer can be provided when the hooks are assigned. This user_data parameter is then provided back the driver whenever any of those hook functions are actually called.

==Sample driver: test_slvreq.c==

A sample 'driver' implementation with support for the <tt>slvreq</tt> functions is [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/test/test_slvreq.c <font color="orange">slvreq</font>:ascend/compiler/test/test_slvreq.c]. This implementation works as follows

* SimulationInstance->slvreq_hooks points to a structure containing the simulation instance pointer together with (optionally) a <tt>slv_system_t</tt> object, '''sys'''. If the system has been built this 'sys' is non-NULL. Otherwise it is NULL. The system is built only once, when the first SOLVER statement is encountered.
* SOLVER command identifies the requested solver, calls 'system_build' if necessary, then selects the found solver on the sys.
* OPTION command checks that system has been built, and searches for the requested option. If found, it sets the value, after first checking that the value provided in the METHOD matches the value type declared in the <tt>slv_parameter</tt> structure.
* SOLVE runs <tt>slv_solve</tt> on the sys, and returns error flags back as needed.
* The main driver is the function <tt>test_slvreq_c</tt>. This essentially just loads a model, instantiates the instance tree, assigned the slvreq hooks, then runs the 'on_load' method.

==Connecting 'slvreq' to the C++ layer==

Connecting the 'slvreq' mechanism to the C++ layer was a bit more complicated. A SolverHooksManager singleton was created which can be assigned with a SolverHooks object. The SolverHooks object has virtual methods for setSolver, setOption, and doSolve. This can be sub-classed according to the user interface. A C++-only test was made ([http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/pygtk/testslvreq.cpp <font color="orange">slvreq</font>:pygtk/testslvreq.cpp] to demonstrate this code in use:

<source lang="a4c">int main(void){

SolverReporter R;
SolverHooks H(R);
SolverHooksManager::Instance()->setHooks(&H);

Library L;
L.load("test/slvreq/test1.a4c");
Type t = L.findType("test1");

Simulation S = t.getSimulation("S");
}</source>

In this implementation, the SolverHooks can be instantiated with a SolverReporter, so that this SolverReporter can be passed by the doSolve when it makes its call to Simulation::solve(solver,solverreporter). If no SolverReporter or SolverHooks are set, then the SolverHooksManager instantiates a default fallback implementation. To get different behaviour, one sub-classes SolverHooks and uses the setHooks call to register the solver hooks that you want, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/pygtk/solverhooks.h <font color="orange">slvreq</font>:pygtk/solverhooks.h]

==Connecting 'slvreq' to the Python layer==

The 'slvreq' functionality is connected to ASCEND's Python API using the SWIG 'director' functionality. This allows the class SolverHooks from the C++ layer to be sub-classed in the Python layer, and the additional of Python-specific or GUI-specific stuff to be done as required.

Here is a first sketch of how this functionality would look from Python:

<source lang="a4c">class PythonSolverHooks(ascpy.SolverHooks):

def __init__(self):
self.mysolver = None
def setSolver(name):

self.mysolver = ascpy.Solver(name)
return 0

def doSolve(inst, sim):
sim.solve(self.mysolver,PythonSolverReporter())

def setParam(*params):
return ascpy.SLVREQ_NOT_IMPLEMENTED

self.L.load('mymodelfile.a4c')

ascpy.SolverHooksManager_Instance().setHooks(PythonSolverHooks())
T = self.L.findType('mymodel')

M = T.getSimulation('sim',False)</source>

This functionality still needs a little re-thinking. In fact, it should not be necessary to pass solver and reporter parameters during the 'sim.solve' call, because the SolverParameters are actually stored in the 'sys' within the 'Simulation', so passing in a new solver is just ambiguous and strange.

However, this is now tested; you can see the test code in [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/test.py <font color="orange">slvreq</font>:test.py].

==Problems and questions==

'''Problem:''' some effort was made (simlist.c) to implement support for multiple SimulationInstances per instance tree. This has never been fully realised (and the merits of this idea are not yet completely clear to me). But the the current slvreq depends crucially on the fact that, within a running METHOD, it's possible to determine what is the current SimulationInstance.

'''Question:''' in some modelling environments, it is possible to define 'subsolvers'. For example, a conditional solver might be able to make use of either [[CONOPT]] or [[IPOPT]] for optimisation, so it might be necessary to provide syntax that would work for this case. Or an optimisation solver might be wrapper around a dynamic solver. Can we support that? What changes would be required?

'''Question:''' is it OK to associate the hook functions with the SimulationInstance? Is there any case where this data should be stored somewhere else?

See also [[Solver NOTES]], another proposed solution to this problem.

==GUI integration==
{{outdated-section}}

This syntax has not yet been incorporated into the ASCEND PyGTK or Tcl/Tk GUI. As a result it's not yet generally usable. The proposed GUI integration flow is something like this:

* GUI is started
* GUI loads a model
* GUI instantiates model
* GUI runs <tt>slvreq_register_hooks</tt>
* libascend stores register hooks in SimulationInstance
* GUI requests 'on_load' method to be run.
* libascend starts executing method statements
* libascend encounters 'USE' statement.
* libascend locates SimulationInstance and find slvreq_hooks object.
* libascend runs slvreq_hooks->set_solver_fn.
* GUI received request to set solver
* GUI checks that solver is elegible for this problem
* GUI sets solver as requests (or writes an error message and returns error code)
* libascend proceeds with more method statements
* libascend find 'SET' statment
* libascend runs slvreq_hooks->set_param_fn (passes string value of requested solver parameter to GUI)
* GUI receives reqest
* GUI either
** finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
** finds that solvername.parametername is not valid, and returns an error code
** finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
** finds that solvername.parametername is not valid, and returns an error code
* finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
* finds that solvername.parametername is not valid, and returns an error code
* libascend proceeds with more METHOD statments...

Controlling the solvers from within METHODS

2010-05-14T07:01:10Z

WikiSysop: Created page with '{{task}} The following new proposed syntax has been introduced into the ASCEND language in a developmental branch called slvreq, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/c…'

{{task}}
The following new proposed syntax has been introduced into the ASCEND language in a developmental branch called slvreq, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/slvreq.h <font color="orange">slvreq</font>:ascend/compiler/slvreq.h].

Support is added for three new statements relating to 'solver requests' in the ASCEND language:

* '''SOLVER''' to specify the solver that should be used.
* '''OPTION''' to specify values for options to be used during solving.
* '''SOLVE''' to actually trigger the user interface to go ahead and solve the MODEL.
<source lang="a4c">MODEL mymodel;
x,y IS_A solver_var;

y = x^2 - x*4 + 4;

METHODS;
METHOD on_load;
FIX y;
y := 0;

SOLVER QRSlv;
OPTION convopt 'RELNOM_SCALE';
SOLVE;
END on_load;

END mymodel;</source>

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=1" title="Edit section: Syntax">edit</a>]==
<pre>
SOLVER solvername;
OPTION optionname valuexpression;
SOLVE;
</pre>

It is proposed to additionally set the syntax for solving particular instances, perhaps as

<pre>
SOLVER solvername WITH myinstance
</pre>

or else perhaps as

<pre>
SOLVE myinstance
</pre>

Both of these have implications for the GUI layer and how it organises itself.

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=2" title="Edit section: Motivation">edit</a>]==

Up until now, the ASCEND language has been carefully designed to avoid polluting the model description with anything relating to actually ''solving'' models; solving was left as something that had to be externally directed, either by .a4s scripts, Python scripts, GUI clicks, or low-level C or C++ code. This has been frequently frustrating when using the PyGTK GUI, because that GUI promotes the idea of being able to just load a model and immediately solve it.

However, many models won't just solve with a simple click of the 'solve' button. Some models need specific solvers to be selected first, and other models will only solve if suitable values of the solver parameters are defined. Neither of these things can be done from within the modelling language, so the result is that the write-test-debug loop for model-making has required the user to either do a lot of spurious clicking to set options each time, or else to write a script to 'drive' ASCEND with the correct settings. Neither of these are particularly user-friendly; [[John Pye]] thinks it should be possible for the user to do 'everything they want' from within a single modelling file.

[[Ben Allan]] has pointed out that such a goal (doing 'everything you want' from within an .a4c file) is unreasonable, because the syntax available within [[METHOD|METHODs]] is too limited to allow anything very sophisticated, and we don't want to develop a full-blown language there. That's a fair point, but the addition of these commands is seen as being so advantageous to user experience that John Pye thought it was worth attempting, regardless.

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=3" title="Edit section: Implementation">edit</a>]==

Implementation of this was complicated, because of the deliberate separation of concerns in ASCEND. We have the '''instance tree''' which is manipulated by [[METHOD|METHODs]], then we have a '''slv_system_t''' which is built (by '''system_build'''), and then a '''solver''' essentially just visits that slv_system_t object in order to solve the model. The solver and its associated parameters exist outside the instance tree, making it hard for a METHOD, which works within the instance tree, to access those things.

A new pointer was added to the <tt>SimulationInstance</tt> object, called <tt>slvreq_hooks</tt>, allowing an ASCEND 'driver' (GUI, command-line interface, test suite, etc) to provide hook functions (via a call to <tt>slvreq_assign_hooks</tt>) to which the different SOLVER, OPTION and SOLVE commands could be passed. What those commands then do is left entirely up to the 'driver'.

Whenever the SOLVER command is encountered, it eventually finds its way to a call to <tt>slvreq_set_solver</tt>. This function locates the slvreq_hooks object in the SimulationInstance, and then, if available, runs the <tt>set_solver_fn</tt> hook function (hopefully) earlier provided by the 'driver'.

The OPTION allows an expression to be provided as its argument. This expression is first evaluated, returning a 'value_t' structure. This value is then passed to <tt>slvreq_set_option</tt>, which then runs the <tt>set_option_fn</tt> hook function earlier assigned, if available.

When the SOLVE command is executed, it calls <tt>slvreq_do_solve</tt> and then <tt>do_solve_fn</tt>.

There is currently no support for solving any MODEL other than that returned from </tt>GetSimulationRoot</tt>. Support for this seems to be a little difficult to design.

As mentioned above, how these functions work exactly is up to the 'driver' to define. Some standard error codes are defined, so that the <tt>Initialize</tt> function in [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/initialize.c <font color="orange">slvreq</font>:ascend/compiler/initialize.c] is able to make sensible error messages for the user. But otherwise, the 'driver' gets to decide.

In order to allow the 'driver' to store implementation-dependent data along with the <tt>slvreq_hooks</tt>, a <tt>user_data</tt> pointer can be provided when the hooks are assigned. This user_data parameter is then provided back the driver whenever any of those hook functions are actually called.

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=4" title="Edit section: Sample driver: test_slvreq.c">edit</a>]==

A sample 'driver' implementation with support for the <tt>slvreq</tt> functions is [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/test/test_slvreq.c <font color="orange">slvreq</font>:ascend/compiler/test/test_slvreq.c]. This implementation works as follows

* SimulationInstance->slvreq_hooks points to a structure containing the simulation instance pointer together with (optionally) a <tt>slv_system_t</tt> object, '''sys'''. If the system has been built this 'sys' is non-NULL. Otherwise it is NULL. The system is built only once, when the first SOLVER statement is encountered.
* SOLVER command identifies the requested solver, calls 'system_build' if necessary, then selects the found solver on the sys.
* OPTION command checks that system has been built, and searches for the requested option. If found, it sets the value, after first checking that the value provided in the METHOD matches the value type declared in the <tt>slv_parameter</tt> structure.
* SOLVE runs <tt>slv_solve</tt> on the sys, and returns error flags back as needed.
* The main driver is the function <tt>test_slvreq_c</tt>. This essentially just loads a model, instantiates the instance tree, assigned the slvreq hooks, then runs the 'on_load' method.

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=5" title="Edit section: Connecting 'slvreq' to the C++ layer">edit</a>]==

Connecting the 'slvreq' mechanism to the C++ layer was a bit more complicated. A SolverHooksManager singleton was created which can be assigned with a SolverHooks object. The SolverHooks object has virtual methods for setSolver, setOption, and doSolve. This can be sub-classed according to the user interface. A C++-only test was made ([http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/pygtk/testslvreq.cpp <font color="orange">slvreq</font>:pygtk/testslvreq.cpp] to demonstrate this code in use:

<source lang="a4c">int main(void){

SolverReporter R;
SolverHooks H(R);
SolverHooksManager::Instance()->setHooks(&H);

Library L;
L.load("test/slvreq/test1.a4c");
Type t = L.findType("test1");

Simulation S = t.getSimulation("S");
}</source>

In this implementation, the SolverHooks can be instantiated with a SolverReporter, so that this SolverReporter can be passed by the doSolve when it makes its call to Simulation::solve(solver,solverreporter). If no SolverReporter or SolverHooks are set, then the SolverHooksManager instantiates a default fallback implementation. To get different behaviour, one sub-classes SolverHooks and uses the setHooks call to register the solver hooks that you want, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/pygtk/solverhooks.h <font color="orange">slvreq</font>:pygtk/solverhooks.h]

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=6" title="Edit section: Connecting 'slvreq' to the Python layer">edit</a>]==

The 'slvreq' functionality is connected to ASCEND's Python API using the SWIG 'director' functionality. This allows the class SolverHooks from the C++ layer to be sub-classed in the Python layer, and the additional of Python-specific or GUI-specific stuff to be done as required.

Here is a first sketch of how this functionality would look from Python:

<source lang="a4c">class PythonSolverHooks(ascpy.SolverHooks):

def __init__(self):
self.mysolver = None
def setSolver(name):

self.mysolver = ascpy.Solver(name)
return 0

def doSolve(inst, sim):
sim.solve(self.mysolver,PythonSolverReporter())

def setParam(*params):
return ascpy.SLVREQ_NOT_IMPLEMENTED

self.L.load('mymodelfile.a4c')

ascpy.SolverHooksManager_Instance().setHooks(PythonSolverHooks())
T = self.L.findType('mymodel')

M = T.getSimulation('sim',False)</source>

This functionality still needs a little re-thinking. In fact, it should not be necessary to pass solver and reporter parameters during the 'sim.solve' call, because the SolverParameters are actually stored in the 'sys' within the 'Simulation', so passing in a new solver is just ambiguous and strange.

However, this is now tested; you can see the test code in [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/test.py <font color="orange">slvreq</font>:test.py].

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=7" title="Edit section: Problems and questions">edit</a>]==

'''Problem:''' some effort was made (simlist.c) to implement support for multiple SimulationInstances per instance tree. This has never been fully realised (and the merits of this idea are not yet completely clear to me). But the the current slvreq depends crucially on the fact that, within a running METHOD, it's possible to determine what is the current SimulationInstance.

'''Question:''' in some modelling environments, it is possible to define 'subsolvers'. For example, a conditional solver might be able to make use of either [[CONOPT]] or [[IPOPT]] for optimisation, so it might be necessary to provide syntax that would work for this case. Or an optimisation solver might be wrapper around a dynamic solver. Can we support that? What changes would be required?

'''Question:''' is it OK to associate the hook functions with the SimulationInstance? Is there any case where this data should be stored somewhere else?

See also [[Solver NOTES]], another proposed solution to this problem.

==[<a href="/index.php?title=Controlling_the_solvers_from_within_METHODS&action=edit&section=8" title="Edit section: GUI integration">edit</a>]==
{{outdated-section}}

This syntax has not yet been incorporated into the ASCEND PyGTK or Tcl/Tk GUI. As a result it's not yet generally usable. The proposed GUI integration flow is something like this:

* GUI is started
* GUI loads a model
* GUI instantiates model
* GUI runs <tt>slvreq_register_hooks</tt>
* libascend stores register hooks in SimulationInstance
* GUI requests 'on_load' method to be run.
* libascend starts executing method statements
* libascend encounters 'USE' statement.
* libascend locates SimulationInstance and find slvreq_hooks object.
* libascend runs slvreq_hooks->set_solver_fn.
* GUI received request to set solver
* GUI checks that solver is elegible for this problem
* GUI sets solver as requests (or writes an error message and returns error code)
* libascend proceeds with more method statements
* libascend find 'SET' statment
* libascend runs slvreq_hooks->set_param_fn (passes string value of requested solver parameter to GUI)
* GUI receives reqest
* GUI either
** finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
** finds that solvername.parametername is not valid, and returns an error code
** finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
** finds that solvername.parametername is not valid, and returns an error code
* finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
* finds that solvername.parametername is not valid, and returns an error code
* libascend proceeds with more METHOD statments...

WITH VALUE

2010-05-14T06:58:43Z

WikiSysop:

{{DISPLAYTITLE:WITH_VALUE}}
{{missing}}
[[Category:Syntax]]

WITH VALUE

2010-05-14T06:58:16Z

WikiSysop:

[[DISPLAYTITLE|WITH_VALUE]]
{{missing}}
[[Category:Syntax]]

WITH VALUE

2010-05-14T06:58:02Z

WikiSysop: Created page with '{{DISPLAYTITLE|WITH_VALUE}} {{missing}} Category:Syntax'

{{DISPLAYTITLE|WITH_VALUE}}
{{missing}}
[[Category:Syntax]]

ABsolver

2010-05-14T06:57:34Z

WikiSysop: Created page with '{{missing}} {{task}}'

Template:Solvers

2010-05-14T06:57:09Z

WikiSysop:

{| border="1" align="right"
|-
! '''[[NLA]]'''
|-
|align="center" bgcolor="#88FF88"|'''[[QRSlv]]'''
|-
|align="center" bgcolor="#88FF88"|'''[[CMSlv]]'''
|-
| align="center" bgcolor="pink"|'''[[IPSlv]]'''
|-
| align="center" bgcolor="#DDDDDD"|'''[[Opt]]'''
|-
! '''[[NLA]]'''
|-
| align="center" bgcolor="#88FF88"|'''[[CONOPT]]'''
|-
| align="center" bgcolor="#88FF88"|'''[[IPOPT]]'''
|-
| align="center" bgcolor="#DDDDDD"|'''[[TRON]]'''
|-
| align="center" bgcolor="#DDDDDD"|'''[[MINOS]]'''
|-
| align="center" bgcolor="pink"|'''[[NGSlv]]'''
|-
| align="center" bgcolor="pink"|'''[[OptSQP]]'''
|-
! '''[[DAE]]'''/'''[[ODE]]'''
|-
| align="center" bgcolor="#88FF88"|'''[[IDA]]'''
|-
| align="center" bgcolor="#88FF88"|'''[[LSODE]]'''
|-
| align="center" bgcolor="#88FF88"|'''[[DOPRI5]]'''
|-
! '''[[LA]]'''
|-
| align="center" bgcolor="#88FF88"|'''[[Linsolqr]]'''
|-

| align="center" bgcolor="#DDDDDD"|'''[[Linsol]]'''
|-
! '''[[LP]]'''
|-
| align="center" bgcolor="pink"|'''[[MakeMPS]]'''
|-
! '''[[Logic Solvers|Logic]]
|-
| align="center" bgcolor="#88FF88"|'''[[LRSlv]]'''
|}
[[Category:Solvers]]

NLP

2010-05-14T06:56:49Z

WikiSysop: Created page with '{{solvers}} {{missing}}'

METHOD

2010-05-14T06:56:37Z

WikiSysop: Redirected page to METHODS

#REDIRECT [[METHODS]]

SELF

2010-05-14T06:56:22Z

WikiSysop: Created page with '{{missing}} Category:Syntax'

{{missing}}
[[Category:Syntax]]

Category:Miscellany

2010-05-14T06:55:53Z

WikiSysop:

This category contains information not directly related to ASCEND, but things which have been of use in our work on or using ASCEND.

The following 12 files are in this category, out of 12 total.

{| class="wikitable"
|-
| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:GSL-1.13.pkg.zip]]</div></div>
<div class="gallerytext">
[[File:GSL-1.13.pkg.zip|GSL-1.13.pkg.zip]]<br />

4,310,999 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Gsl-1.13.exe]]</div></div>
<div class="gallerytext">
[[File:Gsl-1.13.exe|Gsl-1.13.exe]]<br />
1,618,840 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Boost-1.34.1-mingw.exe]]</div></div>
<div class="gallerytext">
[[File:Boost-1.34.1-mingw.exe|Boost-1.34.1-mingw.e...]]<br />
3,582,601 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Buildbot-0.7.5.win32.exe]]</div></div>
<div class="gallerytext">
[[File:Buildbot-0.7.5.win32.exe|Buildbot-0.7.5.win32...]]<br />
432,881 bytes<br />
</div>
</div>|-
| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Buildbot-0.7.6.win32.exe]]</div></div>
<div class="gallerytext">
[[File:Buildbot-0.7.6.win32.exe|Buildbot-0.7.6.win32...]]<br />
476,621 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Coin3d-2.5.0.exe]]</div></div>
<div class="gallerytext">
[[File:Coin3d-2.5.0.exe|Coin3d-2.5.0.exe]]<br />
6,360,050 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Cunit-2.1-jdpipe.exe]]</div></div>
<div class="gallerytext">
[[File:Cunit-2.1-jdpipe.exe|Cunit-2.1-jdpipe.exe]]<br />
93,645 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Graphicsmagick-1.1.10.exe]]</div></div>
<div class="gallerytext">
[[File:Graphicsmagick-1.1.10.exe|Graphicsmagick-1.1.1...]]<br />
2,090,494 bytes<br />
</div>
</div>|-
| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Graphicsmagick-1.2.020071109.exe]]</div></div>
<div class="gallerytext">
[[File:Graphicsmagick-1.2.020071109.exe|Graphicsmagick-1.2.0...]]<br />
3,021,808 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Pycunit-0.2-1.src.rpm]]</div></div>
<div class="gallerytext">
[[File:Pycunit-0.2-1.src.rpm|Pycunit-0.2-1.src.rp...]]<br />
21,593 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Soqt-1.4.1.exe]]</div></div>
<div class="gallerytext">
[[File:Soqt-1.4.1.exe|Soqt-1.4.1.exe]]<br />
1,471,593 bytes<br />
</div>
</div>| <div class="gallerybox" style="width: 155px;">
<div class="thumb" style="padding: 13px 0; width: 150px;"><div style="margin-left: auto; margin-right: auto; width: 120px;">[[Image:Sundials-2.3.0-0.i386.fc6.rpm]]</div></div>
<div class="gallerytext">
[[File:Sundials-2.3.0-0.i386.fc6.rpm|Sundials-2.3.0-0.i38...]]<br />
891,131 bytes<br />
</div>
</div>|}
</div>

Ubuntu installation notes

2010-05-14T06:55:30Z

WikiSysop: Created page with '{{missing}} Category:Miscellany'

{{missing}}
[[Category:Miscellany]]

GraphicsMagick on MinGW

2010-05-14T06:55:18Z

WikiSysop: Created page with '{{missing}} Category:Miscellany'

{{missing}}
[[Category:Miscellany]]

Binary installer for GSL-1.11 on MinGW

2010-05-14T06:55:01Z

WikiSysop: Created page with '{{missing}} Category:Miscellany'

{{missing}}
[[Category:Miscellany]]

Category:Stubs

2010-05-14T06:54:24Z

WikiSysop: Created page with 'These are pages that have been started but still need content to be added before they are fully useful.'

These are pages that have been started but still need content to be added before they are fully useful.

Lower bound

2010-05-14T06:53:48Z

WikiSysop: Created page with '{{missing}} Category:Syntax'

{{missing}}
[[Category:Syntax]]

Upper bound

2010-05-14T06:53:34Z

WikiSysop: Created page with '{{missing}} Category:Syntax'

{{missing}}
[[Category:Syntax]]

RUN

2010-05-14T06:53:20Z

WikiSysop: Created page with '{{missing}} Category:Syntax'

{{missing}}
[[Category:Syntax]]

ASSERT

2010-05-14T06:53:04Z

WikiSysop: Created page with '{{missing}} Category:Syntax'

{{missing}}
[[Category:Syntax]]

METHODS

2010-05-14T06:52:50Z

WikiSysop: /* Built-in methods */

<div class="notice metadata" id="stub">''This article is a '''stub'''. You can help out by <span class="plainlinks">[http://ascendwiki.cheme.cmu.edu/index.php?title=METHODS&action=edit expanding it]</span>. ''</div>

The <strong class="selflink">METHODS</strong> part of a [[MODEL]] is where procedural statements are contained. In this part of your model declaration, you can not declare new [[Variable|variables]] or [[Equation|equations]], but you can set the values of [[Variable|variables]], make [[Equation|equations]] active/inactive, perform bounds checking and run [[External Methods]].

See [[Thin-walled_tank/Adding_methods_to_a_model]] for an introduction to the use of METHODS including some 'standard' method naming conventions.

== Standard METHOD names ==

There is a suggested set of names for METHODs that you should consider using in a model if you would like to make it easy for other people to reuse it. These are

* '''<tt>specify</tt>'''
: In this method, [[RUN]] <tt>ClearAll</tt>, then [[FIX]] any variables that you would like to set as known values.

* '''<tt>values</tt>'''
: In this method, set the values of your FIXed variables.

* '''<tt>default_self</tt>'''
: Set any other default values for variables in your model. Often, setting these default (initial/pre-solve) values this is necessary in order for your model to converge to the desired solution.

* '''<tt>bound_self</tt>'''
: Set the [[upper_bound]] and [[lower_bound]] for any variables that don't already have suitable bounds from their [[ATOM]] definitions.

* '''<tt>[[Scaling|scale_self]]</tt>'''
: Set (or re-set) the scaling for your model. Correct model [[scaling]] is critical for the good numerical behaviour of some models. Sometimes it can even be useful to re-scale the model after solving it with some 'easy' initial conditions.

* '''<tt>on_load</tt>'''
: Write this method to make calls to the other METHODs in suitable sequence. The intention here is that after the GUI automatically runs this method, the model should be in a state where it 'just solves', so that the user can see what the results are.

* '''<tt>self_test</tt>'''
:Write this method with [[ASSERT]] statements to check that your model solves to the expected values. This allows you to quickly check that the model is working as you want, before then proceeding to use it for your other purposes. See [[Model self-testing]].

Sometimes models require an unusual set of METHODs in order to be configured to solve the problem at hand. In this case, it is recommended that instructions for solving your model be added using [[NOTES]] on the model, perhaps giving the notes category as "solving", for example.

== Built-in methods ==

* '''<tt>ClearAll</tt>'''
: This method automatically [[FREE]]s all variables in the whole model tree.

* '''<tt>reset</tt>'''
: This method runs <tt>ClearAll</tt> and then attempts to run the <tt>specify</tt> method. That means that all the FIXed and FREEd varibles should end up reset to their desired states.

[[Category:Stubs]]
[[Category:Documentation]]
[[Category:Syntax]]

METHODS

2010-05-14T06:52:28Z

WikiSysop: /* Standard METHOD names */

<div class="notice metadata" id="stub">''This article is a '''stub'''. You can help out by <span class="plainlinks">[http://ascendwiki.cheme.cmu.edu/index.php?title=METHODS&action=edit expanding it]</span>. ''</div>

The <strong class="selflink">METHODS</strong> part of a [[MODEL]] is where procedural statements are contained. In this part of your model declaration, you can not declare new [[Variable|variables]] or [[Equation|equations]], but you can set the values of [[Variable|variables]], make [[Equation|equations]] active/inactive, perform bounds checking and run [[External Methods]].

See [[Thin-walled_tank/Adding_methods_to_a_model]] for an introduction to the use of METHODS including some 'standard' method naming conventions.

== Standard METHOD names ==

There is a suggested set of names for METHODs that you should consider using in a model if you would like to make it easy for other people to reuse it. These are

* '''<tt>specify</tt>'''
: In this method, [[RUN]] <tt>ClearAll</tt>, then [[FIX]] any variables that you would like to set as known values.

* '''<tt>values</tt>'''
: In this method, set the values of your FIXed variables.

* '''<tt>default_self</tt>'''
: Set any other default values for variables in your model. Often, setting these default (initial/pre-solve) values this is necessary in order for your model to converge to the desired solution.

* '''<tt>bound_self</tt>'''
: Set the [[upper_bound]] and [[lower_bound]] for any variables that don't already have suitable bounds from their [[ATOM]] definitions.

* '''<tt>[[Scaling|scale_self]]</tt>'''
: Set (or re-set) the scaling for your model. Correct model [[scaling]] is critical for the good numerical behaviour of some models. Sometimes it can even be useful to re-scale the model after solving it with some 'easy' initial conditions.

* '''<tt>on_load</tt>'''
: Write this method to make calls to the other METHODs in suitable sequence. The intention here is that after the GUI automatically runs this method, the model should be in a state where it 'just solves', so that the user can see what the results are.

* '''<tt>self_test</tt>'''
:Write this method with [[ASSERT]] statements to check that your model solves to the expected values. This allows you to quickly check that the model is working as you want, before then proceeding to use it for your other purposes. See [[Model self-testing]].

Sometimes models require an unusual set of METHODs in order to be configured to solve the problem at hand. In this case, it is recommended that instructions for solving your model be added using [[NOTES]] on the model, perhaps giving the notes category as "solving", for example.

== Built-in methods ==

* '''<tt>ClearAll</tt>'''
:<dl><dd> This method automatically <a href="/FREE" title="FREE">FREEs</a> all variables in the whole model tree.
</dd></dl>

: This method automatically <a href="/FREE" title="FREE">FREEs</a> all variables in the whole model tree.

* '''<tt>reset</tt>'''
:<dl><dd> This method runs <tt>ClearAll</tt> and then attempts to run the <tt>specify</tt> method. That means that all the FIXed and FREEd varibles should end up reset to their desired states.
</dd></dl>

: This method runs <tt>ClearAll</tt> and then attempts to run the <tt>specify</tt> method. That means that all the FIXed and FREEd varibles should end up reset to their desired states.

[[Category:Stubs]]
[[Category:Documentation]]
[[Category:Syntax]]

ASCEND history

2010-05-14T06:49:50Z

WikiSysop: Redirected page to History of ASCEND

#REDIRECT [[History of ASCEND]]

SWITCH

2010-05-14T06:49:30Z

WikiSysop: Created page with '{{missing}} Category:Syntax'

{{missing}}
[[Category:Syntax]]

CONDITIONAL

2010-05-14T06:49:14Z

WikiSysop: Created page with '{{missing}} Category:Syntax'

{{missing}}
[[Category:Syntax]]