Transform systems robustly by remaking systems #2875
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an attempt to strengthen the robustness of system transformations (i.e. processes that turn one system into another).
Internally, as pointed out in #1710 and #1752, there is inconsistency between
@set! sys.field = value
from Setfield.jl (keeping unspecified fields, but skipping checks).Field dropping has spawned bugs like #2845 and #2502, which usually gets "duct tape patched" by adding that single field for one particular system type. Transforming systems in a uniform way could prevent such bugs in the future, and maybe simplify some internal machinery. Maybe it would also be more efficient to "batch remake" several modified fields with a single new constructor call, rather than
@set! sys.field1 = value1; @set! sys.field2 = value2; ...
which I think calls the constructor several times.Externally, I "envision" that a simple and robust interface could facilitate users making their own custom transformations. Maybe another package using ModelingToolkit would like to build models in a way that requires some simple application-dependent transformation of the system. Every user shouldn't have to reinvent a machinery for doing this themselves.
This is a draft for now. I would really appreciate thoughts and suggestions, or to know if you think this is not a good idea.
Checklist
contributor guidelines, in particular the SciML Style Guide and
COLPRAC.