I’ve been doing mixed simulations (some electronics, some physics, some digital control) for a bit and wrote up a little Pluto notebook comparing a tank circuit simulation in LTSpice and using DiffEq. I was surprised at the speed difference (but probably shouldn’t have been).
It’s posted here: https://klaff.github.io/LTSvDEQ_1.jl.html
Cool! It seems that pluto is having some issues with the html export, I can’t see most of the code cells
Interesting. I didn’t notice that on my PC but on my phone now I see that we’re losing approximately one line at the bottom of code cells which erases the one-liners. Thanks.
Edit @baggepinnen, are you on Android? I get the same on Android with Chrome or Firefox but all looks good on my PC.
I can imagine that the difference is mainly caused by
In addition, I think that the comparison is already somewhat unfair by the fact that SPICE does not use such a specialized solution, since there should still be the possibility to calculate general circuits.
I would love to have a Spice implemented in Julia.
My first paper was based on doing transistor sizing using a Particle Swarm Optimizer.
It has a PSO implemented in Matlab,
and it generated Spice Netlist files (which are plain text and close to a standard format), then triggered Spice to run via a commandline call, imported the CSV of timing results, and processed that to find how long the device took.
Unfortunately, coding a Spice is pretty hard.
It seems all good if its all resitive and inductive loads.
but then you start looking at stuff like Level-6 Transitor models, and the math starts to look scary.
Plus the whole GUI layer is a thing.
Yeah don’t worry, it’ll happen soon.
I am not quite sure if this comparison reveals much. While in (LT)Spice the schematic of the circuit is automatically (and in a pretty direct way) translated into a set of differential and algebraic equations (DAE) and solved by a dedicated solver, for the use of Julia you did the (however easy in this particular case) job of transforming these equations into a set of ordinary differential equations (ODE) first. That is the format of the model that you need to formulate and solve an
ODEProblem in Julia. So here you have already burnt quite some energy in favor of Julia solution. For a circuit of a higher complexity this task of even just formulating (and not yet solving) the differential equations is nontrivial.
The comparison may reveal a bit more if you formulate the model of the circuit as a set of DAEs (equations of the L and C elements and the current source and simple equations modelling the interconnections) and solve it as such in Julia.
I’m working on a more complicated example in that very direction!
If you implement it in ModelingToolkit, it will automatically convert the DAEs to the ODE, so that’s not big deal. It would be a good tutorial to add to MTK though.