Let us begin by answering the question in the title which is no. This post presents arguments behind that answer.
In a recent substack post, Ben Recht mentioned that Mosek and optimization software in general have many algorithmic parameters that can be tweaked. Clearly, it may be overwhelming for the average user of optimization software to figure out what the parameters do and how to change them.
Note that the types of parameters that are referred to are those that affect the algorithms of the optimizers and not the parameters that affect things like the amount of log output.
However, in the case of Mosek a good rule of thumb is to only tweak the parameters if there is a very good reason to do so. The main reasons for this are:
- The default values of the parameters are chosen after extensive testing. Hence, it is hard to improve the average optimizer performance by tweaking the parameters.
- If it is easy to devise a rule that automatically improves the performance of Mosek by adjusting a parameter, then such a rule would be built into Mosek.
- Mosek is only tested extensively for the default parameter settings and hence weird things can happen for non-default parameter settings. For instance, the stopping criteria employed by the interior-point optimizer normally would lead to the most accurate solution possible. Therefore, tightening the stopping criteria in most cases increases the number of iterations(=work) and results in no or minimal benefit.
Given the above arguments an obvious question is then, why are so many parameters made available to the users of Mosek? The two most common reasons are:
- For instance, the mixed-integer optimizer can take a lot of time to solve a problem to optimality and therefore it might be relevant to relax the stopping criteria to obtain a less accurate but decent solution in a reasonable amount of time.
- Mosek implements many heuristics that make beneficial algorithmic choices. An example is, decide whether to solve the problem on primal or the dual form in the case of interior-point optimizer. This heuristic is not perfect and in some cases, it is worthwhile to override it.
- Occasionally Mosek has a bug or simply performs poorly on specific problems. In such cases, a tweak in the parameter settings may provide a good workaround.
To summarize, based on 25 years of experience, parameter tweaking rarely solves performance or robustness issues. Indeed it is rarely the quick fix a user might hope for. The correct fix is in most cases to improve the model formulation by avoiding bad scaling, big Ms etc.
As an exception to the general rule mentioned in the conclusion, let us finish by listing the parameters
that are the most common to tweak:
- Relaxing the stopping criteria of the mixed integer optimizer i.e. relax the relative gap tolerance.
- Turn the linear dependency checker off in the presolve because the computational cost of the procedure is not worth the benefit. This is often the case when the constraint matrix is generated from a finite element model.
- Force an optimizer to employ a specific number of threads e.g. setting the number of threads to one in the case when multiple problems are solved in parallel.
