Only linear solver mumps works but too slow

[andrcoding]

Hello,

I have extended my model by some more time steps. Unfortunately, this runs into a solution time issue and convergency problem. Therefore, I wanted to try out different linear solvers.

Mumps could solve the problem in a time which is not feasible for me as I have to run the problem multiple times. Setting the linear solver to one of the solvers out of the HSL package results in a local infeasibility (Test Unit and a mwe worked fine). Changing the starting point was unsuccessful, too. Attached are sample log files.

Has someone an idea regarding my parameter settings or a clue why I do not converge with the HSL solvers.

PS: I have to use Ipopt on a Windows/Java setup.

3.13.3_wo_hsl-ok.log
3.13.3_w_hsl-failed.log

[cjl88]

I built IpOpt with:
./configure --with-lapack="-L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lm"

"If you want to compile Ipopt with the Pardiso library that is included in Intel MKL, it is sufficient to ensure that MKL is used for the linear algebra routines (Blas/Lapack), see BLAS and LAPACK."

So I get Pardiso by default, it is faster than Mumps in my case.

[andrcoding]

As the new versions of Pardiso are claimed to be faster than the MKL version, I actually wanted to test this one directly. However, I think there is no fitting library available for my situation. In addition, the MKL version also only works with an MS compiler, doesn't it?

[svigerske]

Pardiso from pardiso-project seems to be available for Linux only at the moment: https://pardiso-project.org/#binaries

Pardiso from MKL is available for Linux, macOS, and Windows. I could imaging that it also works with gcc on Windows and not only MS/Intel compilers, but one would need to try that out.

[andrcoding]

This is also my level of information. I will test it with gcc and the MKL version. Thanks

[svigerske]

The logs don't look as if it is the linear solver that decided on whether you find a feasible point or not. Changing the linear solver just changes the solution path and in the run with MA97 it quickly went into a local infeasible point, while in the run with MUMPS it didn't (well, it eventually gave up with an "acceptable point"), but it could very well have been the other way around as well. Keeping the linear solver fixed and changing some Ipopt parameters may have a similar effect. I cannot give good advice on which parameters to change. Revisiting your problem formulation could also be direction to pursue.

[andrcoding]

Unfortunately, my problem has many local optima. I have tested several formulations including relaxing some constraints without success. I have tried many settings for the parameters. However, I will have a look again at the list.
Basically, I can also specify a feasible starting point. However, attempts were also unsuccessful. Can I force a feasible solution path?
Regarding the linear solvers, I have originally assumed that the basic solution is the same (apart from the parallel solvers) and that there is only a difference in the computations. Thus, I will use one fixed linear solver for further testing now.

[svigerske]

If the starting point is feasible, but close to variable bounds, then setting bound_frac and bound_push may help to avoid that Ipopt moves the point away from the bounds before starting.

Maybe setting the (undocumented) parameter theta_max_fact to some smaller value will force more feasible solutions.

theta_max_fact: Determines upper bound for constraint violation in the filter.

    The algorithmic parameter theta_max is determined as theta_max_fact times the maximum of 1 and the constraint violation at initial point. Any point with a constraint violation larger than theta_max is unacceptable to the filter (see Eqn. (21) in the implementation paper).

    Range: (0, ∞]

    Default: 10000

Differences in computations can give different solutions and thus different solution paths. There is no basis in Ipopt.

[cjl88]

I am using MKL version on Linux.On Mar 15, 2021 9:28 AM, andrcoding ***@***.***> wrote: As the new versions of Pardiso are claimed to be faster than the MKL version, I actually wanted to test this one directly. However, I think there is no fitting library available for my situation. In addition, the MKL version also only works with an MS compiler, doesn't it? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.