Fix dual type promotion in remake with dummy derivatives

[hersle]

This seems to fix the minimal example in #3336.

I am still having problems with a slightly more complicated example, though.

[ChrisRackauckas]

This is at least a reasonable thing to do.

[ChrisRackauckas]

Actually no, this can be unsafe. Instead of generating a new variable (which might not match the other if metadata is applied), you'd want to do it the transform the same way the initialization problem does it.

https://github.com/SciML/ModelingToolkit.jl/blob/master/src/systems/nonlinear/initializesystem.jl#L51

Though I am a bit confused, u0map is already processed right there?

[hersle]

What does the schedule.dummy_sub do differently? Preserve any variable metadata?

[ChrisRackauckas]

It's grabbing the variable itself that already exists, rather than making a new one. The new one is a new symbol which is not guaranteed to match the actual dummy derivative.

[hersle]

Ok, thanks. Is this better?

[hersle]

Though I am a bit confused, u0map is already processed right there?

But yes, it is probably better to do this higher up in the call hierarchy, in case other functions also depend on the dummy derivative substitution being performed? Where would that be?