fix: consider type of t0 in promote_u0

[AayushSabharwal]

Close SciML/ModelingToolkit.jl#2721

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

Add any other context about the problem here.

[ChrisRackauckas]

This isn't necessarily correct. If these things are 3 different duals we should error. It needs to try to promote to the common dual type or error.

[AayushSabharwal]

Fixed

[AayushSabharwal]

This apparently breaks tests, since in some cases it tests with two different duals. Previously, if u0 was a dual it would return u0 without checking if p is a dual or trying to promote. I added the same thing here to make tests pass. Should it be reverted, and the tests updated accordingly? And if so, wouldn't that be breaking?

[ChrisRackauckas]

What's the state here?

[AayushSabharwal]

promote_type(::Type{Measurement}, ::Type{ForwardDiff.Dual}) is ambiguous. I'm fairly certain Dual{Measurement} is what this should be, but wanted confirmation. I'll PR to the appropriate repository with an extension and then hopefully tests will pass here.

[ChrisRackauckas]

We just need to handle Measurement differently. Does this actually show up in the tests?

[AayushSabharwal]

Yes https://github.com/SciML/DiffEqBase.jl/actions/runs/9250766919/job/25444939597?pr=1039

[ChrisRackauckas]

. I'm fairly certain Dual{Measurement} is what this should be

I think the other way around, Measurement with dual numbers in it. Make a PR to Measurements.jl

[AayushSabharwal]

Turns out that's not possible because Measurements requires that the wrapped type be <:AbstractFloat which Dual isn't

[ChrisRackauckas]

Ask Mose if that can be relaxed.

[AayushSabharwal]

It seems unlikely given JuliaPhysics/Measurements.jl#100 (comment). Also relaxing that would require breaking Measurements

[ChrisRackauckas]

Okay then we should just change the test if that's fundamental

[AayushSabharwal]

I'm not entirely sure why that test has duals in tspan. It looks like it's meant to test that the rhs function is unwrapped when the unknown is a measurement, which is already tested. If it's meant to test that this also works when t isa Dual then the test simply won't run, so it might as well be removed.

[ChrisRackauckas]

Yeah seems fundamental. I think it can be removed as it was only working because the expected conversion, i.e. differentiation of the solve, didn't actually take place.