Evaluate ngspice

[samreid]

See https://github.com/concord-consortium/build-ngspice-js

[samreid]

There are many unknowns about getting this to work and the odds are extremely low that it would serve as a drop-in replacement in time for July. I'm unassigning for now.

[samreid]

Some notes in case we want to investigate this further, if we are running into too many physics bugs in the modified nodal analysis + companion models, etc.

-s MAX_SETJMPS=50 is not working out of the box with latest emscripten. I can't get a build to complete by following those instructions, perhaps other updates are necessary to use latest emscripten. I haven't tried downloading a legacy emscripten.

if we are using spice, we would solve for initial dc operating conditions. Then run transient analysis and enact on the sim. When the user changes topology or closes a switch or changes the circuit, capture the current values as initial conditions for the next run. Then in next run, skip initial operating conditions, and instead use specified initial conditions. Simulate, say 1 second at a time, then re-solve. Will there be significant CPU demand during the solve? Will we be able to match phase exactly to keep the motion continuous? Will either of those problems cause a stutter?

Manual is here: http://ngspice.sourceforge.net/docs/ngspice-30-manual.pdf

This branch has a checked in build https://github.com/concord-consortium/build-ngspice-js/tree/gh-pages

[samreid]

After discussion, it seems we will need to continue developing our own physics engine, addressing corner cases as we come across them. We suspect there will be too much overhead in calling to emscripten in each timestep. We may be able to leverage it by reading the source code or asking developers questions.

[samreid]

A new project called ngspice.js has been created, it's listed here: https://ngspice.js.org/. Since we are running into so many problems with the solver, we should re-evaluate suitability of a strategy like that. For example: https://ngspice.js.org/?gist=f416efb827fa91fd7badacc588c55bd8

UPDATE: Here is a WebAssembly SPICE implementation: https://github.com/danchitnis/EEsim

[samreid]

Chapter 19 of the spice manual http://ngspice.sourceforge.net/docs/ngspice-manual.pdf describes how to call into the spice library like so:

ngSpice_Command (" circbyline fail test ");
ngSpice_Command (" circbyline V1 1 0 1");
ngSpice_Command (" circbyline R1 1 0 1");
ngSpice_Command (" circbyline . dc V1 0 1 ");

[samreid]

We discussed this briefly today. We will need to publish soon even if there are corner cases that have difficulty, but this could be a possibility for future versions.

[samreid]

Today I noticed that https://github.com/danchitnis/EEsim seemed to have a lot of good progress recently.

UPDATE: As of Oct 18 2022, Firefox is not supported, sadly. Maybe we can help with that?

[samreid]

I tested https://eesim.dev/ in mac firefox 105.0.3 (64-bit) and it worked great! (Same result for same netlist in chrome).

[samreid]

I created a label for the model issues that could be solved by an improved circuit solver (currently 6 of them): circuit-construction-kit-common:model

https://github.com/danchitnis/EEsim is still getting active development, and licensed as MIT. Does it support Firefox yet? How difficult would it be to integrate with the simulation?

This page says Firefox is currently at 0/9 support, but in next firefox (111) it would be at 4/9: https://wpt.fyi/results/workers/modules/dedicated-worker-import.any.html?label=master&product=chrome%5Bstable%5D&product=firefox%5Bstable%5D&product=safari%5Bstable%5D&product=chrome%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned&view=subtest

But testing on Firefox 109.0.1 (64-bit), the example page is working well.

[samreid]

This project looks promising: https://github.com/danchitnis/ngspice