fix: avoid generating massive functions in get_mtkparameters_reconstructor

[AayushSabharwal]

This used to be the lion's share of the compile time in large models. The infrastructure added here might be useful in other places too, as a way to build simple one-off observed functions that mostly access u/p.

[KristofferC]

Good to go?

[AayushSabharwal]

No, pretty significant test failures. Some I can't easily reconcile.

[KristofferC]

Which ones? It is hard to get an overview when a lot of tests typically fail on master as well. What is expected to pass / fail?

[AayushSabharwal]

(1, ModelingToolkit/InterfaceII) should only fail with BVP-related stuff. QA should fail. lts and pre tend to be slightly stochastic depending on which runner we get, but should mirror the corresponding failures on master. Catalyst and SciMLSensitivity should pass. All the failures are related to the typeasserts in MTKParametersReconstructor. I'm working on finding a fix.

[KristofferC]

Claude said something like:

The problem is in the MTKParametersReconstructor callable. CopyParamsByTemplate uses vcat internally, which can
  promote element types (e.g., if observed values return Float64 while tunables are Float32). The code then does a hard
  type assertion (::tunable_T) which fails instead of converting.

So perhaps do a conversion instad of a type assert, like:

diff --git a/lib/ModelingToolkitBase/src/systems/problem_utils.jl b/lib/ModelingToolkitBase/src/systems/problem_utils.jl
index 22c0bcb3..03ea9f2d 100644
--- a/lib/ModelingToolkitBase/src/systems/problem_utils.jl
+++ b/lib/ModelingToolkitBase/src/systems/problem_utils.jl
@@ -878,25 +878,25 @@ function (recon::MTKParametersReconstructor)(src, dst)
         tunablevals = recon.tunables_fn(src)
     else
         tunable_elT = promote_type(eltype(dst_ps.tunable), eltype(src_ps.tunable))
+        tunablevals = recon.tunables_fn(src)
         if ArrayInterface.ismutable(dst_ps.tunable)
             tunable_T = Base.promote_op(similar, typeof(dst_ps.tunable), Type{tunable_elT})
-            tunablevals = recon.tunables_fn(src)::tunable_T
         else
             tunable_T = StaticArraysCore.similar_type(typeof(dst_ps.tunable), tunable_elT)
-            tunablevals = recon.tunables_fn(src)::tunable_T
         end
+        tunablevals = convert(tunable_T, tunablevals)::tunable_T
     end
     if dst_ps.initials isa SVector{0}
         initialvals = recon.initials_fn(src)
     else
         initial_elT = promote_type(eltype(dst_ps.initials), eltype(src_ps.initials))
+        initialvals = recon.initials_fn(src)
         if ArrayInterface.ismutable(dst_ps.initials)
             initial_T = Base.promote_op(similar, typeof(dst_ps.initials), Type{initial_elT})
-            initialvals = recon.initials_fn(src)::initial_T
         else
             initial_T = StaticArraysCore.similar_type(typeof(dst_ps.initials), initial_elT)
-            initialvals = recon.initials_fn(src)::initial_T
         end
+        initialvals = convert(initial_T, initialvals)::initial_T
     end
 
     nonnumerics = recon.nonnumerics_fn(src)

maybe?

[AayushSabharwal]

No, the vcat will have the correct type. The typeassert itself is wrong. I think I have something that works locally, just checking against every failing test.