[Roman Parise] and [Georgios Is. Detorakis] have created OpenSPICE a fork of the PySpice project, adding a new simulation engine written entirely in Python. This enables the same PySpice simulations to be executed on any platform that runs python (which we reckon is quite a few!) whilst leveraging the full power of the python infrastructure. Since it is a fork — for supported platforms — you can also run your simulations upon Ngspice as well as Xyce, giving options for scaling up to larger systems when required, but importantly without having to recreate your circuit from scratch.
The OpenSPICE simulator first converts the parsed netlist into a set of data structures that represent the equations describing the various parts of the system. These are then in turn passed along the scipy library “optimize.root” function which solves the system, generating a list of branch currents and node voltages. The output of the simulation is a numpy array, which can be further processed and visualized with the mathplotlib library. All pretty standard stuff in python circles. Since this is based upon PySpice, it’s also possible to use KiCAD netlists, so you have a nice way to enter those schematics. We’ve not dug into this much yet, but support for the vast libraries of spice models out there in circulation would be high up on our wish list if it already can’t handle this. This scribe will most definitely be checking this out, as LTSpice whilst good, is a bit of a pain to use and does lack the power of a Python backend!
OpenSPICE may well be a good starting point for learning about circuit simulations, without the steep learning curve of some simulation platforms and all the worry about installing and maintaining prerequisites. Why not give it a whirl?
We cover the important task of circuit simulation a fair bit, here’s an example of using LTSpice to simulate guitar peddles. Need to simulate huge systems and have an equally huge compute cluster to hand? You need Xyce. Finally, let’s not forget to mention that the excellent (commercial) MicroCap simulator was released for free, after the retirement of the maintainer. What a gift!
Header: Harland Quarrington/MOD, OGL v1.0.
For those readers who want to see the actual OpenSPICE code: https://github.com/thejackal360/OpenSPICE/tree/master/PySpice/Spice/OpenSPICE
Well -> for me <- the main features of a transient circuit simulator are speed, speed and speed. Hence i would never ever want to implement the core simulator in Python. So what other reasons are there that would justify the massive speed loss?
It is not implemented in Python though. It just runs good old ngspice.
For those who are interested in the actual code:
https://github.com/thejackal360/OpenSPICE/tree/master/PySpice/Spice/OpenSPICE
But why would you want to implement such a time-critical piece of code (as a transient-circuit-anaylsis-solver) in python? What is the benefit in comparison to the ngspice interface?
Answer to myself: Well, okay, there are some arguments in the article, but none of them could convince me. Think about that: LTSpice got this far because it is free and one of the fastest – if not the fastest – transient circuit simulator. Especially for professional use, speed really matters. I think OpenSPICE is a dead horse, sorry.
As Joseph Eoff already said, Python handles the interface to:
“PySpice is a Python module which interface Python to the Ngspice and Xyce circuit simulators” citation from the PySpice Github space. So speed mainly depends on those simulators, not on python.
I recently started studying computational linguistics. Which is mainly Maschine Learning (ML) with very large datasets. And it is common to use just this configuration: python with libraries or interfaces to the ML algorithms written in c – sometimes even assembler if heavy computation is nessesary.
It uses NumPy and SciPy for the heavy lifting. Those libraries are made for scientific calculations. They use optimized C code, with the binaries wrapped for use in Python.
Python handles the IO and getting things into organized for use with NumPy.
Simulation speed shouldn’t be a problem.
Uh, OK. So if I understand correctly, they replaced an existing SPICE written in C by SPICE written in Python and the argument for it being somewhat fast is that most of it actually still runs in C. Well, I can live with the knowledge I won’t understand everything.
Interesting, but not leaving LTSpice. If you need Python backend, try PyLTSpice.
SPICE simulator in Python, eh? So it’s not only slow, but also a resource hog. Seriously, why no one is writing major projects in C++, or in any other compiled programming language? Are people too lazy or too incompetent?
You know, what might be quite powerful? More complex SPICE-like simulation that runs on GPU. Modern GPUs offer quite a big boost for parallel processing with lots of RAM to store relevant data. Imagine real-time SPICE modeling of complex analog circuits with live value tweaking.
THIS^^^ Yeah just reading the writeup made my head hurt with all of the gymnastics. To each their own I guess but I’ll probably stick with LTSpice for the time being. This just seems like a wheels wrapped in a wheel.
It’s worth emphasising that the code doing the hard part is not actually written in python, it’s a well optimised piece of code for root finding from scipy. So you get the benefit of a flexible and easy to hack on library for SPICE simulations that can also leverage well optimised numerical code at its core. It’s a win-win.
Not really. I’ve seen this with bCNC 3 years ago – visual processing for paths was done with scipy and numpy, which both are written in C++ (IIRC), but everything else was in Python with some UI library. It was slow to render, and had a tendency to crash on my older computer, when I tried to load and render more complex jobs. And by default it limited, how much of the path it would show to limit processing required. Mach3, which is an old piece of software, was slow to render, too, but it never crashed and had no limits.
Python is great for education, smaller projects and scripting, but I wouldn’t use it for anything complex or serious. It’s not optimized for such tasks.
It’s kind of weird to talk about how fast and optimised you expect everything to be in one breath, and that you’re using an old computer in the next.
Actually makes a lot of sense, since if software is well optimized, it doesn’t need the latest hardware. A lot of current software really eats away at RAM and has less good text rendering (thinking of Electron apps).
Unfortunately, having several such apps open also eats up modern computers RAM fast.
Yes! I think much of it is written in Cython, which I personally find a delight to use.
It’s amazing to me how many people seem to miss the point you’re raising. Your point is absolutely correct.
The python library is just providing a frontend to the optimized and compiled traditional spice backend. It’s not meant to replace the spice version someone is currently using and happy with. It allows automation and doing simulations without using a traditional frontend, then having the data automatically in an environment you can then further process the results with. Conveniently, it also sounds like it should allow kicad schematics to be used as an input, perhaps enabling chaining a design workflow with some automated parameter optimization, or at the very least some sanity checking before moving to the PCB layout.
I’m a bit lost on the many versions of Spice. I’m using a few. Of which, I like LTSpice the post, except for the lack of standard components not from Linear.
I’d like to read a blog on the history of spice, and why we need to many. As in, Version X runs on obscure hardware, Version Y has a brighter interface but is obsolete now, etc. Free and opensource is great, but standardization for software beats a shiny new version every week.
You can download models, open them in LTSpice, rightclick name of instance and autogenerate a symbol. Then you just make it visually nice. Or not. But getting models work in LTSpice is not hard at all if you try to find out how it works.
Also – SPICE is the thing running as backend which does the calculations and is the important part for getting results. The graphical thingy is just a GUI for SPICE, it may kill the usability of the SPICE, but even if you have great GUI, but botched SPICE, all you get is garbage. And that’s why people use LTSpice. The GUI is somewhat oldschool but extremely fast to use once you learn keyboard bindings, and you are nearly guaranteed the results won’t be a freak show. Which is something you risk when trying these “forks of forks of SPICE3 forks rewritten in otherworldly languages”. One of many great thing about LTSpice is that it almost never runs into non-converging results. And if it does, it’s almost always a nasty model of a component which does not represent reality.
I’ve created a lightweight Python module used to control ngspice simulations. I was surprised how easy it is to convert Spice output to Numpy and plot with matplotlib. Within a few months, I’ll publish a few video tutorials about it.
I think you meant ‘pedals’.
The article is all about OpenSPICE, a python SPICE engine. The actual code is here: https://github.com/thejackal360/OpenSPICE/blob/master/PySpice/Spice/OpenSPICE
OpenSPICE shall replace the alternative SPICE versions as ngspice and xyce.
For all those guys claiming no speed loss due to using Numpy and Scipy:
https://github.com/thejackal360/OpenSPICE/blob/master/PySpice/Spice/OpenSPICE/solve.py#L172-L187
In every f***ing time step this bunch of code is called. You do not want to compare the execution time for a single cycle with (even a naive) a c/c++ implementation. Honestly, Python is a great tool, but this is not its primary purpose.
If it’ll run in micro python next we can run the spice sim on the embedded circuit I want to simulate. It’s python the whole way down (until the bottom layer which is a python simulator running in doom on a toaster)
PySpice can only support up to NgSpice 34. I was wondering if OpenSpice can support the latest version of NgSpice. Thanks!