SciML / ModelingToolkit.jl

An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations
https://mtk.sciml.ai/dev/
Other
1.41k stars 204 forks source link

Bye bye ₊, use var symbols with . #2798

Closed ChrisRackauckas closed 3 months ago

ChrisRackauckas commented 3 months ago

This is something that was iteratively chipped away at during the v9 changes. The last thing left here was the handling of FuncAffect, which needed to have a funky reindexer to handle the fact that u.resisitor.v is done in two getproperty calls, and so we have to lazily merge the symbols.

This is non-breaking because we've been very specific to not rely on any of the symbol names in v9 for a very good reason, and this is that reason. I'm sure someone out there did hardcode ₊ stuff against all recommendations though...

I need to fix the printing in SymbolicUtils.jl to really finalize this change.

ChrisRackauckas commented 3 months ago
julia> rc_model
Model rc_model with 1 equations
Unknowns (1):
  capacitor.v
Parameters (3):
  resistor.R [defaults to 2.0]
  capacitor.C [defaults to 1.0]
⋮
Incidence matrix:1×2 SparseArrays.SparseMatrixCSC{Num, Int64} with 2 stored entries:
 ×  ×

julia> equations(rc_model)
1-element Vector{Equation}:
 Differential(t)(capacitor.v) ~ capacitor.i / capacitor.C

julia> unknowns(rc_model)
1-element Vector{SymbolicUtils.BasicSymbolic{Real}}:
 capacitor.v

julia> parameters(rc_model)
3-element Vector{SymbolicUtils.BasicSymbolic{Real}}:
 resistor.R
 capacitor.C
 source.V

julia> observed(rc_model)
19-element Vector{Equation}:
 source.v ~ source.V
 capacitor.p.v ~ capacitor.v
 capacitor.n.v ~ -0.0
 ground.g.v ~ 0.0
 ⋮
 source.p.i ~ source.i
 capacitor.p.i ~ -capacitor.n.i
 source.n.i ~ -source.p.i

and plot naming is fixed

Screenshot 2024-06-12 094250

isaacsas commented 3 months ago

Instead of hard-coding this character would it make sense to have a ModelingToolkit.SEPERATOR_CHARACTOR or such global variable downstream libraries and MTK could reuse?

ChrisRackauckas commented 3 months ago

I don't know if we can actually support that given how . ties into getproperty.