Remove high relative tolerance on VMCON QPP

[timothy-nunn]

This should go some of the way to improving the performance of VMCON, particularly when running a scan #3957.

I noticed that when running a scan over the same point (e.g. sweep = x, x, x, ..., x) VMCON would perform many iterations on the non-first scan points. This does not make any sense because, after the first scan point, PROCESS is at a converged solution and VMCON should immediately identify this and not perform any iterations. I have verified that old VMCON did this as expected.

VMCON's convergence criteria has two components:

• $|\nabla f(x)\cdot\delta|$: the predicted change in the objective function if VMCON is allowed another iteration.
• $\sum^m_{i=1}|\lambda_{i} c_i(x)|$: the complementary error.

In new VMCON, the first term was much higher than old VMCON, causing new VMCON to not believe it is converged and iterate in search of a solution. This was being driven by a difference in $\delta$. And the reason $\delta$ was different is because the relative tolerance on the quadratic programming solver was so high.

With this PR:

• The $\delta$ calculated by new VMCON and old VMCON are near identical.
• A PROCESS scan of the same point correctly does not iterate and converges immediately.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.34%. Comparing base (ec3fdee) to head (da49b7b).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3964      +/-   ##
==========================================
- Coverage   45.98%   43.34%   -2.65%     
==========================================
  Files         123      123              
  Lines       28550    33509    +4959     
==========================================
+ Hits        13129    14523    +1394     
- Misses      15421    18986    +3565     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[timothy-nunn]

Here is some data to highlight the impact of this PR. PROCESS has broadly three methods of termination:

• Converging: a sufficiently feasible and locally-optimal solution is found
• Crashing: a Python error occurs in one of the models, often the Newton failure (Newton solve crashing when calculating t_zero_margin #3674)
• QSP failing: VMCON's quadratic programming problem solver fails, often because the problem appears locally infeasible when linearised.

I have performed a Monte Carlo experiment of PROCESS runs within +/-30% of the initial starting point of the large_tokamak_nof and st_regression input files, totalling 2000 input files run per configuration.

The first configuration uses VMCON 2.4.0 (new VMCON) with the old high QPP tolerance. As can be seen, there is no significant difference in the number of converging runs before and after this change.

1290 runs that converged before this change still converge. 36 runs that used to crash now converge, and 27 that used to converge now crash.

The second configuration used VMCON 2.3.1 (old VMCON) with the new lower QPP tolerance. I had to upgrade CVXPY to 1.7.3 because there was a lot crashes from within CVXPY that this release--or possibly another release >=1.7.1--fixes. Again, there is no significant changes in the number of converging runs.

The final configuration combined all of these changes to use the new lower QPP tolerance, VMCON 2.4.0, and CVXPY 1.7.3. There is a significant, but not disastrous, change in the number of converging runs. Many runs that used to converge now crash within the models.

Generally, I do not find these results to be concerning as hopefully #3674 will allow many more of these to converge.