Improve robustness of t_zero_margin calculation with brentq fallback

[chris-ashe]

Description

Checklist

I confirm that I have completed the following checks:

• My changes follow the PROCESS style guide
• I have justified any large differences in the regression tests caused by this pull request in the comments.
• I have added new tests where appropriate for the changes I have made.
• If I have had to change any existing unit or integration tests, I have justified this change in the pull request comments.
• If I have made documentation changes, I have checked they render correctly.
• I have added documentation for my change, if appropriate.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 46.31%. Comparing base (466247d) to head (d667b8b).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
process/superconducting_tf_coil.py	73.68%	5 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4018   +/-   ##
=======================================
  Coverage   46.30%   46.31%           
=======================================
  Files         123      123           
  Lines       28961    28974   +13     
=======================================
+ Hits        13411    13419    +8     
- Misses      15550    15555    +5     

☔ 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]

I still need to think about this and test it a bit more. This doesn't fix the problem, but I am not so sure there is a solution: we are at a garbage point in the parameter space where a positive solution does not exist.

This PR will stop PROCESS from crashing and instead it will (probably) fail to converge.

The only thing I need to convince myself of is that -1 is an acceptable fallback. Could this -1 end up in the availability model or a constraint, cause that model to be wrong, but we somehow converge?

[timothy-nunn]

I'm still thinking so no rush with these changes. I think this mixture of local/global is redundant and might even cause the two to be different at points in the execution.

[timothy-nunn]

Suggested change

	temp_tf_superconductor_margin = -1.0e0 # Default value in case of exception

Remove this default and use the variable tfcoil_variables.temp_margin, I think having the local variable is redundant

[timothy-nunn]

Suggested change

	temp_tf_superconductor_margin: {temp_tf_superconductor_margin}
	temp_tf_superconductor_margin: {tfcoil_variables.temp_margin}

[timothy-nunn]

Suggested change

	if temp_tf_superconductor_margin <= 0.0e0:
	if tfcoil_variables.temp_margin <= 0.0e0:

[timothy-nunn]

Suggested change

	return tfcoil_variables.temp_margin

[timothy-nunn]

Hi @mkovari, could I request your review here. Chris has added two methods to try and find the root using both brentq and newton. If both of these fail (e.g. because there is no root for a positive temp) then we fall back to a linear approximation that uses the gradient of the margin_func close to $0$. This is not a physical approximation but will provide a negative temperature, if there is a temperature margin constraint in use then using a linear approximation will ensure there is a gradient for the solver to use to try and fix it (although in my tests this problem occurs in garbage regions of the domain where the solver gives up with or without a temperature margin constraint).

Here is what the approximation looks like between temp=$5$ and the root from the linear approximation:

And here it is zoomed in around 0: