I'm not sure why CI isn't running. Will also figure out a way to do this so I don't get the credit for MTKStdlib

Benchmark Results (Julia vlts)

Benchmark Results (Julia v1)

I don't think we want to keep most of these libraries. Most of the Dyad versions are also open sourced and at this point better maintained. Which of the sublibraries here are not covered by the main Dyad component libraries? It seems it might just be a documentation thing where we should just link to all component libraries out there in the ecosystem, which should include the Dyad ones but also AI4E or whichever ones people develop.

@baggepinnen I know you have opinions on this, are there any that we should bring "in house" to MTK here?

I don't particularly mind what we keep in MTKStdlib. My motivation for moving this here is that any breaking release has to jump through too many hoops because tests depend on MTKStdlib. We can recommend users use Dyad libraries, but I strongly oppose the use of Dyad models in our tests.

@baggepinnen which standard libraries are worth preserving? Copying conversation into here,@SebastianM-C mentioned:

Dyad is very opinionated on what representation to pick. MtKStdLib has things like Mechanical.Translational, MechanicalPosition, MechanicalModelica

@baggepinnen

Getting rid of all of those in favor of the Dyad (modelica) one would be welcome

And yes, I agree that having 3 mutually incompatible versions of the Mechanical library, where 2 are effectively pretty broken in most scenarios, doesn't serve anyone. Since Dyad's MechanicalComponents.jl is a more complete version of MechanicalModelica and it's BSD-3 licensed like the Modelica Standard Library, there is 0 possible advantage to having a separate MechanicalModelica since it's just a less maintained version of it. But while we're at it, we might as well remove the two bad ones. So that means all of the mechanical components should be removed and we should just tell people to use MechanicalComponents.jl

But is every library like that? ElectricalComponents.jl as well. etc. Multibody2D: should we separate that out to a different repo? Is it being maintained? It's just aLink component and nothing else?

From a cursory look by me, it looks like the only thing to really keep then is the digital components from ElectricalComponents should be moved to ElectricalComponents.jl. Maybe some of the block components to. But we don't want anything else out of these libraries at this point if I'm not mistaken?

I strongly oppose the use of Dyad models in our tests.

If we need to have small versions of ElectricalComponents or something as a sublibrary like ModelingToolkitTestComponents.jl in order to make testing easier, that's fine. But that's very different from having two versions of the standard library (or with mechanical components, 4 😅 where we tell people to not use 3 of them!) Just from a signaling standpoint, I think 99% of people are just better off if we tell them to use the one that's maintained, which is not the one there. That repo has been a bit of a trap.

Multibody2D: should we separate that out to a different repo? Is it being maintained? It's just a Link component and nothing else?

Remove it, connectors there do not transmit torque so it's pretty broken. Multibody.jl has a complete version of planar mechanics.

There have been some improvements to some components that aren't present in modelica stdlib, but I think we should just add those to dyad as well

At least "Basic Blocks" libraries andInterpolation,ParametrizedInterpolation,SampledData, ... components sound domain-independent and generically useful to me and makes sense to have in a standard library.

Electrical/magnetic/mechanical/thermal/... components sound more specialized and domain-specific to me, and could make sense both inside/outside a standard library, depending on what one is going for.

At least "Basic Blocks" libraries and Interpolation, ParametrizedInterpolation, SampledData, ... components sound domain-independent and generically useful to me and makes sense to have in a standard library.

Yes, these should live as a sublibrary here in alib folder. That will keep them better maintained and stop them from breaking 😅 . ModelingToolkitNeuralNets.jl should arguably be a lib folder too.