Perhaps this is the problem: the workings of the model isn't separated from the interface to it?
Yes, I believe so.
Unfortunately, that choice itself is a huge divide in the software world. We have the integrated framework approach, and we have the modular minimalism approach. Even talking about this I risk starting a flamewar.
(Don't mistake my choice of mascot as an ideology or zealotry. I've worked with both proprietary and open source code, and signing NDAs has never been a problem for me. What I do trust, is the test of time and use cases, rather than the opinion of some "authority", though.)
AFAIK, the model complexity has zero to do with the GUI.
Exactly.
If the user interface was separated from the actual simulator, other schematic capture programs could use it as a simulator, and different user interfaces for the same simulator to support different workflows.
There are some YT videos where Engelhard explains why and how LtSpice has superior math compared to other Spices.
Mike Engelhardt is the author of LTspice, and the only one with access to its sources. I'm very hesitant to believe
any authors word as to why their solution is superior, if I cannot verify it for myself.
This is not a slight on Engelhardt, mind you. I apply the same,
strictly, to my own solutions and even examples and suggestions. I never just claim something; I always show how to verify the claim for yourself.
Agree the GUI is totally disconnected from the simulation engine and models.
Except in the case of LTspice, where they are inseparable, even though we have the exact information that the simulation engine needs.
The practical result of this is that LTspice only runs on Windows (7-10) and MacOS (10.15+) on x86 and x86-64, and has a single user interface.
This sidetrack started because I mentioned I've seriously considered writing my own (portable) schematic capture and symbol editor on top of ngspice.
To make it worthwhile, I'd need to do what I usually do when designing a serious user interface, and examine the actual work flow of both professionals and hobbyists. That way, I can make it
efficient. I'm pretty good at that, actually; I typically end up significantly speeding up users' workflows.
The problem in this is that many professionals, for some reason, completely drop interest when they find out it would use ngspice instead of ltspice, and I cannot understand why. I
know ltspice is a faster simulator, but nothing I've seen indicates it is more precise, numerically stable, or otherwise more reliable than ngspice. Just faster.
There already exist a number of user interfaces to do this. KiCad 7 and later are the most accessible (as in, both free, and available for most operating systems and architectures), but
there are quite a few others.
Thus, in a very real sense, it is very, very much about the user interface, and not really about the simulator engine itself at all (except that because of Mike's choices, we cannot use LTspice's engine only; we either use the engine and its UI, or not at all).
From practical experience, the user interface affects your workflow efficiency more than you think or feel. When you use a specific interface long enough, it does become muscle memory and thus both fast and with low cognitive load, but before that, you end up wasting a lot of time and effort before you get there. (Plus, it is said that a human can get used to and comfortable with anything at all, possibly excepting an icicle up their butt, because that will melt before you get used to it.)
For example, there is no
good technical reason why simulation results are not shown as the simulation progresses, why running a simulation should preclude other work on the schematic or symbols, or why you couldn't run several simulations (with the same or different schematics) in parallel. (KiCad 7 + ngspice precludes all those; I'm not sure about LTspice on native Windows/MacOS.)
It all depends only on the UI, and exactly how the UI is connected to the simulation engine.
And my point is, we fundamentally could do better with what we already have, except
users are not interested in helping to find out what that "better" would be. It seems the more professional you are, the more intent you are in hoping for an Authority like Mike Engelhardt tells you what that is.