[Breaking change] Change names to follow JSO conventions

[sshin23]

This PR makes several changes in the struct/function/variable names to comply with JSO conventions. These changes include

• InteriorPointSolver to MadNLPSolver
• Logger to MadNLPLogger
• Counters to MadNLPCounters
• optimize! to solve!
• ips to solver
• ips.l to ips.y

[codecov-commenter]

Codecov Report

Merging #194 (e43e15b) into master (03d728e) will increase coverage by 2.94%.
The diff coverage is 91.99%.

@@            Coverage Diff             @@
##           master     #194      +/-   ##
==========================================
+ Coverage   72.78%   75.72%   +2.94%     
==========================================
  Files          38       37       -1     
  Lines        3424     3468      +44     
==========================================
+ Hits         2492     2626     +134     
+ Misses        932      842      -90     

Impacted Files	Coverage Δ
lib/MadNLPKrylov/src/MadNLPKrylov.jl	0.00% <0.00%> (ø)
lib/MadNLPPardiso/src/MadNLPPardiso.jl	100.00% <ø> (ø)
lib/MadNLPPardiso/src/pardiso.jl	0.00% <0.00%> (ø)
src/KKT/KKTsystem.jl	97.29% <ø> (ø)
src/LinearSolvers/backsolve.jl	100.00% <ø> (ø)
src/LinearSolvers/linearsolvers.jl	0.00% <0.00%> (ø)
src/MadNLP.jl	60.00% <ø> (-2.50%)	⬇️
src/options.jl	85.71% <ø> (ø)
src/Interfaces/MOI_interface.jl	71.74% <75.00%> (ø)
src/utils.jl	68.42% <75.00%> (ø)
... and 25 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f718b56...e43e15b. Read the comment docs.

[frapac]

To me, the renaming makes a lot of sense. I just have a doubt for solve!, I think I still prefer optimize!. The reasons are:

• the words optimize conveys more meaning than just solve (mathematics is all about solving equations, whereas optimizing is more context specific).
• JuMP/MOI are both using optimize!

But I am open to any counter argument!

[sshin23]

@frapac, the goal of using solve! is to import SolverCore.solve! later. In that way, one can implement a unified solver interface for solvers (e.g., in BlockNLPModels.jl)

[frapac]

I see. And how about doing?

function solve!(::MadNLPSolver, nlp::AbstractNLPProblem)
     solver = MadNLPSolver(nlp)
     MadNLP.optimize!(solver)
end

I don't have any strong opinion about this too. My main concern is to have an easy interface if we have to re-solve the problem.

[sshin23]

@frapac the current solve! allows efficient resolve, but I see your point. Then optimize! will be an internal function that doesn't require the second argument nlp. I think that might actually be better because the JSO convention for solve! requires the second argument nlp

[frapac]

My other concern is that the API in SolversCore.jl is not fixed yet, with a PR opened since Mar 29, 2021. I think we should expect some changes in the naming on their side too, at least till the PR is not merged.

[sshin23]

@frapac Good point. I think we can hold until this PR gets merged
JuliaSmoothOptimizers/SolverCore.jl#26

[frapac]

Looks good to me!