-
-
Notifications
You must be signed in to change notification settings - Fork 209
Optimisation Modelling Advice
Advice on constructing mathematical programming models with ojAlgo
Don't use the various solvers directly. ExpressionsBasedModel should always be your starting point. Be sure to read its documentation and have a look at The Diet Problem example.
If you need to solve a large number of small models; then maybe bypassing ExpressionsBasedModel is preferable. In this case it is still recommended that you start using ExpressionsBasedModel, and get rid of it later.
Fewer variables and expressions is practically always better. Adding auxiliary variables and expressions may make the model easier to construct and/or read, but most of the time it becomes harder to solve.
Model entities (variables and expressions) can contribute to the objective function and be constrained (at both ends) simultaneously - do not create separate expressions to define multiple properties.
Encode as much as possible on the variables directly. The variables are model entities just like expressions. Do not create single variable expressions. What ever properties you intend for that expression you can set on the variable directly, and that's much more efficient.
In most cases it is not beneficial to model redundant constraints. In particular; if a constraint is an inequality (open at one end) then leave it as such. Do not insert some artificial limit/bound on the open side.
ojAlgo's built-in solvers can handle linear and/or convex (quadratic) problems with or without integer variables. When/if you're constructing non-linear expressions you have to make sure they actually are convex. This does not happen automatically.
Currently (still) the built-in solvers can not handle quadratic constraints.
You should pay attention to what numbers are actually fed to the model - extremely large or small numbers can cause problems. Internally ExpressionsBasedModel stores all model parameters as BigDecimal. If you supply the model parameters as BigDecimal then you control the precision and scale of the model parameters, and you should actively set the precision and scale of the model parameters.
The ExpressionsBasedModel has a public 'options' attribute through which you control model/solver behaviour. If the solvers can't handle your model you should experiment with different settings. In particular you should turn on validation:
model.options.validate = true;
The presolver functionality of ExpressionsBasedModel is an important part of the model-solve-chain. These are implemented as a collection of individual plug-ins - they can be (individually) turned off and you can add other/new ones.
ojAlgo comes with a collection of built-in pure Java solvers. ExpressionsBasedModel analyses the model and selects the appropriate solver. It's possible to specify additional solvers with different capabilities, and these will be used seamlessly by ExpressionsBasedModel. Optimatika has built three such 3:d party solver integrations:
These are all top-tier (non-Java) commercial solvers with performance on a whole different scale from ojAlgo's built-in pure Java solvers. To use these you do not alter the model in any way. All you do is:
ExpressionsBasedModel.addIntegration(...);
In fact this is a key feature of ojAlgo. Not only is it one of the very few options for mathematical optimisation on the JVM, but when the supplied solvers aren't enough you switch to some alternative solver simply by registering its integration.