JOM (Java Optimization Modeler)

Solvers' parameters information

The method solve of the OptimizationProblem object, attempts to solve the defined optimization problem calling the solver. This method permits the user defining a set of parameter-value pairs, to tune the solver operation. Some of these parameters are defined by JOM, the others are solver-specific, and what JOM does is just passing these parameters to the solver.

This page contains relevant information about how to tune the solver operation and the solve method.

Common parameters to all solvers

These parameters are common to all solvers:

Parameter name	Value type	Information
`solverLibraryName`	String	Permits the user determining a full or relative path (including the file name) of the dynamic library file (.dll in Windows, .so in Linux systems) that contains the code of the solver. If this parameter is not set in the call to `solve` method, JOM: In Windows systems tries to find the file `glpk_4_47.dll` for GLPK, `Iopt38.dll` for IPOPT and `cplex122.dll` for CPLEX. Note that if a single file name is provided, Windows tries to find it in the directories in the PATH variable. In non-Windows systems tries to find the file `libglpk.so` for GLPK, `libipopt.so` for IPOPT and `cplex.so` for CPLEX. This parameter is not used in MIPCL solver, that should be installed according to the instructions in MIPCL site.
`maxSolverTimeInSeconds`	double	(new from JOM 0.1.12) A `double` number should be associated to this parameter. JOM conveys to the solver the time limit information setting the internal solver parameters: `tm_lim` in GLPK (sets the maximum time in miliseconds, JOM translates `maxSolverTimeInSeconds` to that), parameter code `1039` (constant `CPX_PARAM_TILIM`) in CPLEX, and parameter `max_cpu_time` in IPOPT. If optimality is not reached before, the solver stops after this time returning the best feasible solution found so far. The user should check if the solution is optimal (using `solutionIsOptimal ()` method) or even feasible (using `solutionIsFeasible ()` method), since the solver may fail to provide even a feasible solution in the granted time. GLPK and CPLEX seem to accurately respect the time limits set. However IPOPT uses some internal linear solvers that do not do that. Then, it is possible that IPOPT does not meet the time limits. This is not a JOM limitation, but a documented solver issue.

MIPCL parameters

These parameters only take effect when the chosen solver is MIPCL.

Parameter name	Value type	Information
`dualityGapLimitInAbsoluteValue`	double	The solver will stop and return the best solution found so far, when it finds a solution for which it can guarantee that has a cost that is at most `dualityGapLimitInAbsoluteValue` units worse than the optimum cost. This option only applies in MIPs (that is, when at least one variable has integrality constraints), and is ignored in regular LPs. For LPs, also the `maxSolverTimeInSeconds` option is ignored by the solver.

GLPK parameters

These parameters only take effect when the chosen solver is GLPK. Below there is a list of the main parameters of GLPK. For a complete list, please see the GPLK documentation.

Parameter name	Value type	Information
`glpkSolverType`	String	This parameter can take the values "simplex" or "interior-point". When the problem has no integer variables, the simplex algorithm or the interior-point algorithm built-in in GLPK are used to solve the problem, depending on this parameter. If the problem has integer variables, this parameter is not used, since GLPK gives no choice to select the type of algorithm for solving the problem. See the GLPK documentation for more information.
`msg_lev`	int	Message level for terminal output (default: no output - default option changed in JOM respect to normal GLPK default): 0 \| no output 1 \| warning and error messages only 2 \| normal output 3 \| full output (including informational messages).
`meth`	int	For simplex solver: Simplex method option (default: use two-phase primal simplex). 1 \| use two-phase primal simplex; 2 \| use two-phase dual simplex, and if it fails, switch to the primal simplex 3 \| use two-phase dual simplex
`it_lim`	int	For simplex solver: Simplex iteration limit (default: INT_MAX - no limit in practice)
`tm_lim`	int	For simplex solver: Searching time limit, in milliseconds. (default: INT_MAX - no limit in practice)
`presolve`	int	For simplex and MIP solver: LP presolver option. (default: presolver is enabled - default option changed in JOM respect to normal GLPK default) 1 \| enable using the LP presolver 0 \| disable using the LP presolver

IPOPT parameters

These parameters only take effect when the chosen solver is IPOPT. Below there is a list of the main parameters of IPOPT. For a complete list, please see the IPOPT documentation (here is the appendix with the IPOPT options).

Parameter name	Value type	Information
`print_level`	int	Output verbosity level. Sets the default verbosity level for console output. The larger this value the more detailed is the output. The valid range for this integer option is an integer between 0 and 12 (both included), and its default value is 0 (the original default for IPOPT was 5, but JOM makes the default become 0).
`print_options_documentation`	String	Switch to print all algorithmic options. If selected, the algorithm will print the list of all available algorithmic options with some documentation before solving the optimization problem. The default value for this string option is "no". Possible values: "no" \| don't print the list "yes" \| print the list
`max_iter`	int	Maximum number of iterations. The algorithm terminates with an error message if the number of iterations exceeded this number. The valid range for this integer option is any non-negative integer, and its default value is 3000
`max_cpu_time`	double	Maximum number of CPU seconds. A limit on CPU seconds that Ipopt can use to solve one problem. If during the convergence check this limit is exceeded, Ipopt will terminate with a corresponding error message. The valid range for this real option is any non-negative double, and its default value is 1 million of seconds
`derivative_test`	double	Enable derivative checker. If this option is enabled, a (slow!) derivative test will be performed before the optimization. The test is performed at the user provided starting point and marks derivative values that seem suspicious. The IPOPT default value for this string option is "none", but JOM changed the default to "first-order". Possible values: "none": do not perform derivative test first-order: perform test of first derivatives at starting point second-order: perform test of first and second derivatives at starting point. This option does not work in JOM since second-order derivatives are always approximated setting the IPOPT option "hessian_approximation" to value "exact". only-second-order: perform test of second derivatives at starting point. This option does not work in JOM since second-order derivatives are always approximated setting the IPOPT option "hessian_approximation" to value "exact".

JOM automatically sets some parameters, overriding any value suggested by the user:

When JOM knows that the constraints of the problem are all linear, then JOM sets the IPOPT parameters jac_c_constant and jac_d_constant to "yes". By doing so, JOM informs IPOPT that the jacobian (first derivative) of the constraints is a constant. Then, IPOPT evaluates this jacobian only once and reuses this information later, saving computational resources. When it is not true that all the constraints are linear, jac_c_constant and jac_d_constant are set to "no". In this case, JOM implements the callback functions that evaluate the first derivative of the constraints. Note that the user does not need to worry about these computations.
When JOM knows that the problem is linear (both objective function and constraints), then JOM knows that the hessian matrix (second derivative) of the Lagrange function is zero. In this case JOM sets the IPOPT parameter hessian_approximation to "exact" and the parameter hessian_constant to "yes". The former parameter informs that JOM will be in charge of evaluating the hessian (a matrix of all zeros in this case), the second that the hessian is a constant matrix, so IPOPT needs to evaluate it only once. Both options help to speed-up IPOPT execution for linear problems. When the problem is not linear, JOM sets the parameter hessian_approximation to "limited-memory" and hessian_constant to "no". Then, IPOPT is in charge of approximating the hessian matrix. Thanks to this IPOPT option, JOM does not need to implement the callbacks that evaluate the hessian matrix of the Lagrange function.