feat: add substitute_component

[AayushSabharwal]

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.

[AayushSabharwal]

I agree that that would be a great syntax. However, we use Setfield internally to update systems and this might conflict with that. Additionally, the setproperties approach would only go one level deep. If a user did @set sys.inner.component.child = newchild, this would first replace child in component, then use that to replace component in inner, then use that to replace inner in sys which is a lot of unnecessary work.

[SebastianM-C]

I've tested this locally a bit and I have a case where eq.rhs is a (top level) connect equation and the args are ModelingToolkit.SymbolicWithNameof and then getname(arg) gives the Symbol("var_name(t)") variant instead of just :var_name. I saw that using getname(arg.var) works, but I'm not sure if that makes sense since the resulting system crashes on printing during n_expanded_connection_equations 😅.

[AayushSabharwal]

Oh oops, I always forget that SymbolicWithNameof exists. Thanks for pointing it out.

[cstjean]

We could really use this functionality, but unless I'm mistaken the requirements limit its applicability.

5. rhs must contain at least all of the unknowns and parameters present in lhs.

Eg. "What if we replaced this continuously-stirred tank with a non-stirred tank?" might not meet these requirements, right? Or "ComplexReactorModel => NaiveReactorModel".

I understand that there's probably an efficiency reason for these constraints, but in this case I would rather have inefficient-and-general than efficient-but-limited.

My use case is for running experiments. "What if we replaced component A.B.C with C2(...)?" is much nicer to write than copy-paste the A and B @mtkmodel definitions and reconnect everything.

Is there another way of doing this?

[AayushSabharwal]

I understand that there's probably an efficiency reason for these constraints, but in this case I would rather have inefficient-and-general than efficient-but-limited.

It's not an efficiency but correctness issue. It's really difficult to see how a component (and all subcomponents) are used across the entire model and then verify that the replacement has the same pieces. I'd be more than happy to work on it in the future, but this addresses a limited set of problems with scope for expansion in the future.

The way to do this is define the model with an "interface component" - one which isn't intended for simulation but has the bare minimum interface required to connect with the rest of the system. This can then be replaced to form different model variants.