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 parametervalue pairs, to tune the solver operation. Some of these parameters are defined by JOM, the others are solverspecific, 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 nonWindows 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 "interiorpoint". When the problem has no integer variables, the simplex algorithm or the interiorpoint algorithm builtin 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 twophase primal simplex).
 1  use twophase primal simplex;
 2  use twophase dual simplex, and if it fails, switch to the primal simplex
 3  use twophase 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 nonnegative 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 nonnegative 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 "firstorder". Possible values:
 "none": do not perform derivative test
 firstorder: perform test of first derivatives at starting point
 secondorder: perform test of first and second derivatives at starting point. This option does not work in JOM since secondorder derivatives are always approximated setting the IPOPT option "hessian_approximation" to value "exact".
 onlysecondorder: perform test of second derivatives at starting point. This option does not work in JOM since secondorder 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 speedup IPOPT execution for linear problems. When the problem is not linear, JOM sets the parameter hessian_approximation to "limitedmemory" 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.
