It's probably not obvious to people outside the community, but the amount of effort that's currently going into MTK and the larger SciML stack is absolutely enormous. Depending on how you count, maybe an order of magnitude more than is currently going into Julia proper. By my count at least 30 talks at JuliaCon this year were about SciML applications. That whole ecosystem is really taking off.
That's wild. I can tell SciML has a huge scope & is moving very rapidly, but I couldn't have made the comparison to Julialang itself.
It really feels like a gold rush to me, like the grand visions of the early computer science pioneers (Englebart, Licklider, Kay...) coming to life.
I'm curious what the emergent properties of large Julia codebases will be. The composability of Julia packages helps keep things modular, but there are places it breaks down (ex: Unitful x AbstractArray x Zygote), and those are the places where the expression problem sets back in & toolkits revert to frameworks.
OTOH, multiple dispatch makes it easier to dissolve the entanglement -- refactoring of the package dependency structure. That makes it possible for alternate solutions to get hot-swapped into the system if they prove advantageous. Formal interfaces would streamline this in a big way.
It's really two separate problems but they kinda interact.
Unitful quantities with heterogeneous units don't have a `zero` function that works correctly, which gets in the way inside numerical routines. [0] There are other places where 0 or 1 is added, which is an error for quantities but not for plain real numbers. [1]
Optimization problems take a vector of parameters. If you want to put units on your quantities & then optimize, you'll end up with this issue. Another instances is with vectors in general coordinates: (r,z,\theta) or (x,y,z,t) have tangent vectors with heterogeneous units too.
Isn't a "vector" of parameters is really more of a tuple since they don't follow the vector laws and have fixed types in each field? Why do they use Base.Vector?
No, it is still base vector but with more structure, and not tuple. I would guess that the parent is talking about the general case, e.g. in (general)relativity where the vector laws you mention are not as simple as you think, i.e. they transform with a “metric” which is not simply the identity (non-Euclidean or non cartesian). It seems to me that this “metric” is a matrix of interunit conversions, though, so it is not that complicated either. In other words, (the Jacobian of) coordinate transforms (in your words, “vector laws”) can be expressed as Base.vector extended with unit conversion. In summary, general coordinates follow a nontrivial vector law where the units for each element of the array are not fixed/the same. E.g. cylindrical coordinates like the parent mentions, the si units are (m, m, rad) which still transform as a vector under the metric mentioned in [1] but which have heterogeneous units
How is the symbolic transformation approach different between Modia and ModelingToolkit for ODEs ? I would guess Modia probably uses the same method as Dymola but not sure if MTK has any specific advantages here.
As of now, Modias DSL feels more familiar and less boilerplate-y to me (as a modelica dev) but I guess that's probably because they just focus on similar capability to Modelica unlike MTK which has a lot of expandability.
With that being said, having a decent component library (like MSL) and a GUI (or preferably some auto diagram) to compose and browse through them would be the minimum needed to be able to beat Modelica in the acausal modeling space.
