inequality equation is checked without any margin

[jjwalkowiak]

Describe the issue

I don't know if this is a bug or a feature, but the current setup of the solver stops around 20% of my cases from converging and adds unnecessary iterations to most of them. I think since: #3238 the constrains have no error-margin when they are evaluated, so if I push to many limits at once, I can't get convergence just because of the numerical accuracy.

The solver is very unreliable because of that and small changes to the input can decide between converged/non-converged solution. See #3330 for example

In my fork I just changed one line https://github.com/ukaea/PROCESS/blob/165fcc553ec0c50a0d7070494e17c6ab9a4d21c1/process/solver.py#L209C13-L209C50

from:
return bool(np.all(result.ie >= 0.0))
into:
return bool(np.all(result.ie >= -1e-8))

And it saves me a lot of trouble with non-converged cases. I don't see a reason to push it to the exact 0.0, but maybe I miss something. Also, I assumed that it checks the normalized residue, so 1e-8 seems a reasonable margin. But if this is non-normalized value or something completely different, then maybe this limit should be different.

[jonmaddock]

Hello @jjwalkowiak , thanks for this issue. You are quite right.

The reason we added this requirement to fully satisfy the inequality constraints was mainly due to #3081 (see comment at bottom of issue), where the convergence criterion in the solver could allow inequalities to be substantially violated (provided their associated Lagrange multiplier was small enough) and still converge. We wanted to ensure that the design was actually feasible, rather than it being OK to be inequality-violated if the objective function wasn't sensitive to that constraint being violated.

Further, we required that inequality constraints should be satisfied with no tolerance (as you point out in #3238): there isn't really a good reason why inequality constraints should be violated at all if a feasible solution exists, and we required this for a study. We therefore denied the solver convergence and required it to look harder, which appeared to work in most cases.

However, as you say, in practice this can result in the solver going around in (tiny) circles and refusing to converge, even when a zero-tolerance feasible solution may well exist. I suspect this is due to precision or linearisations in the solver.

I think it's probably a good idea to allow some tolerance in the inequality constraints as a compromise as you suggest: we've been discussing this internally too. This would still solve the problem in #3081 where the violations could be high, but also alleviate this convergence issue. I'll add this to our board.

[timothy-nunn]

Hi @jjwalkowiak

We have taken some time to discuss this internally and have implemented a proposed fix in #3858. If approved and merge, the option for a zero-tolerance inequality constraints will be available in the input file (and will be off by default).

The inability of the solver to reach zero-tolerance was (in my opinion) because VMCON and almost all other constraint solvers are not designed to exactly satisfy all constraints--they only do so to a reasonable tolerance (e.g. 1e-8). When the residual on constraints is low, the solver focuses on optimising and does not consider trying to make the solution 'more' feasible.

Thanks again for the issue and for contributing to the discussion around whether this was a good idea.

Cheers,
Tim