I had not seen this thank you
NetworkDynamics is more limited than GraphDynamics in the sense that we are very strickt about the “interface” between nodes and edges. Its main goal is to simulate systems which have “flows” on edges and “potentials” on nodes. While the dynamics themself can be heterogeneous (MTK models on edges and vertices, only subset of MTK supported), the interface is not (for example in PowerDynamics each edge model calculates currents based on nodal voltage, each nodal model calculates voltage based on current). Making the graph structure explicit is very good for component reuse across topologies, componentwise initialization and addressing of components/states based on their position in the network. We have some experiments for simulating gas and district heating networks with it as well (finite volume discretization along the edges, single finite volumes as nodes). But we specificially do not represent all discretization points as individual nodes in our network, a full pipe would just become a single edge model with N internal states for N finite volumes.
So GraphDynamics seems like the more efficient way to do it: don’t discard the structure and directly use it for codegen. But it is not flexible, no index reduction etc.. So that’s where the DCP would come in as a general solution: let mtkcompile simplify the system and do all the MTK magic, and add compiler passes in codegen to reduce the equation size. @dhairyagandhi96 is there any timeline for the DCP to become publicly available? I would love to give it a try.
What are the benefits of NetworkDynamics.jl as far as scaling the system to potentially thousands of nodes and edges vs plain MTK?
This approach of edges and nodes seems to be the way. The mass conservation and energy conservation are solved at the nodes/volumes, and momentum equations on the edges.
NASA’s Generalized Fluid System Simulation Program uses this approach and probably other commercial softwares as well.
So pre MTK@v11 the scaling of MTK systems was a much bigger problem. In NetworkDynamics our backend is not symbolic at all, its just Julia code. So our symbolic simplification and code gen stops at the component level. To make it concrete: in PowerDynamics you will normally use dynamic models like generators in the order of 5-30 states (up to ~300 eqs pre simplification maybe). The symbolic simplification pipeline only sees those equations, simplifies and emits Julia code. In the network you can then use the same compiled components 5 or 5000 times – no more symbolic handling needed. ND tries to keep lots of the benefits which come from symbolic modeling though, for example hooking into SymbolicIndexingInterface for inspecting removed/observed states of the compiled component models after solve.
On old MTK versions modeling those kinds of systems would not have been feasible, MTK simply couldn’t scale to systems with tens of thousands equations – this might have changed in v11.
In MTK v11 the structural simplification got much faster, but it creates one big RHS function. That just doesn’t scale well, at some point this RHS function gets very big which is very slow to compile. So I will give NetworkDynamics.jl a try.
Looking at Bart’s model, it’s purely a mass-spring model. I.e., it’s not a multibody system with rigid bodies but instead more of a “reinforcement learning gym” type of robotics model. My assumption is that probably is an artifact of making an MWE since most Dymola-style multibody models do not simplify down to that structure, but 
yeah if the MWE does match the complexity of the true system, then it would fall into the GraphDynamics sphere. Though GraphDynamics is missing some of the linearity specializations that RL gym types of simulators would focus on.
Yes, but the true system also has a lot of repeated structure. The models that are slow to compile with MTK are slow because they have a lot of point masses and rigid bodies. Models with less points / rigid bodies but the same complexity are sufficiently fast to compile.