Fixes issue #234 using same inputs

[matthew-kapp]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

• Fixes issue Thermal.FixedHeatFlow cannot actually model a fixed heat flow rate source #234
• The issue seems to be that if alpha is 0, the symbolic compiler will create an equation with 0 division
• This has been solved using an ifelse statement
• The functionality remains the same including inputs
• Not sure whether to update the docstring, so this remains as-is
• A MWE test is adapted from issue Thermal.FixedHeatFlow cannot actually model a fixed heat flow rate source #234 as follows:

using OrdinaryDiffEq, ModelingToolkit
using ModelingToolkitStandardLibrary.Thermal
using ModelingToolkit: t_nounits as t

@mtkmodel TestModel begin
    
    @components begin
        temp = FixedTemperature(T=300)
        heatflow = FixedHeatFlow(Q_flow=-1.0)
        wall = ThermalResistor(R=1)
    end

    @equations begin
        connect(temp.port, wall.port_a)
        connect(wall.port_b, heatflow.port)
    end

end

@mtkbuild test_model = TestModel()
for eq in observed(test_model)
    println(eq)
end
prob = ODEProblem(test_model, Pair[], (0, 10.0))
sol = solve(prob)

Output before:

temp₊port₊T(t) ~ temp₊T
heatflow₊port₊Q_flow(t) ~ wall₊Q_flow(t)
wall₊port_a₊Q_flow(t) ~ wall₊Q_flow(t)
wall₊port_b₊Q_flow(t) ~ -wall₊Q_flow(t)
temp₊port₊Q_flow(t) ~ -wall₊Q_flow(t)
wall₊port_a₊T(t) ~ temp₊port₊T(t)
heatflow₊port₊T(t) ~ (-heatflow₊port₊Q_flow(t) + heatflow₊Q_flow*(-1 + heatflow₊T_ref*heatflow₊alpha)) / (heatflow₊Q_flow*heatflow₊alpha)
wall₊dT(t) ~ temp₊port₊T(t) - heatflow₊port₊T(t)
wall₊port_b₊T(t) ~ heatflow₊port₊T(t)
retcode: InitialFailure
Interpolation: 3rd order Hermite
t: 1-element Vector{Float64}:
 0.0
u: 1-element Vector{Vector{Float64}}:
 [NaN]

Output after:

temp₊port₊T(t) ~ temp₊T
heatflow₊port₊T(t) ~ -wall₊dT(t) + temp₊port₊T(t)
wall₊port_a₊T(t) ~ temp₊port₊T(t)
heatflow₊port₊Q_flow(t) ~ ifelse(heatflow₊alpha == 0.0, -heatflow₊Q_flow, heatflow₊Q_flow*(-1 + (heatflow₊T_ref - heatflow₊port₊T(t))*heatflow₊alpha))
wall₊port_b₊T(t) ~ heatflow₊port₊T(t)
wall₊Q_flow(t) ~ heatflow₊port₊Q_flow(t)
wall₊port_a₊Q_flow(t) ~ wall₊Q_flow(t)
wall₊port_b₊Q_flow(t) ~ -wall₊Q_flow(t)
temp₊port₊Q_flow(t) ~ -wall₊Q_flow(t)
retcode: Success
Interpolation: 3rd order Hermite
t: 9-element Vector{Float64}:
  0.0
  1.0e-6
  1.1e-5
  0.00011099999999999999
  ⋮
  0.11111099999999996
  1.1111109999999995
 10.0
u: 9-element Vector{Vector{Float64}}:
 [1.0]
 [1.0]
 [1.0]
 [1.0]
 ⋮
 [1.0]
 [1.0]
 [1.0]

This MWE has been added as a test, which passes

[matthew-kapp]

@ven-k there's now additional tests failing. I'll need to debug first.

[matthew-kapp]

@ven-k all tests pass again

[ven-k]

Not strictly necessary, but I would suggest merging first two commits as they don't stand independently.
In future PRs I'd suggest "Update with rebase" option instead of merging main (for cleaner git history).

I have the foll. question, otherwise this looks good.

[ven-k]

Why is this pinned to a version?
If at all this is only to set a lower bound, it would be better to not add =. These tend to constraint package resolutions while using with other packages.

[matthew-kapp]

Hi @ven-k good point. As mentioned in Issue #371 the latest version causes tests to fail. So does it make sense for Symbolics to first be fixed or how to deal with this?

[ven-k]

Symbolics 6.30 is yanked from the registry now. The pin can be removed.

[matthew-kapp]

@ven-k all done

[ven-k]

The failing unit-tests are unrelated to this PR.

(Note that formatter failure is related)