I am using LTSpice XVII under WINE in Linux. The sim works when I start out but then fails (become inaccurate) after a time spent adding, moving and deleting components. If I wipe everything back to the simple start circuit it does not work correctly as it did originally, although the signal sources do.
Is this a known problem and is there any way to get around it?
Perhaps it is the circuit. I don't mean to insult, but from your postings w e can tell there are a few holes in your knowledge base.
If nothing else changed it is probably your changes. you need to do things the old way, you should already know how it works, every waveform, every vo ltage. At one time it was all done on paper (or actually napkins at the gre asy spoon restaurant).
I can design you an amp, an SMPS and a few other things on paper but I have a shit ton of trouble with doing it on the computer. So I still do it (whe n I do) on paper.
I think everyone should be given a pad of the graph paper and made to actua lly draw out things, and label it with all expected waveforms and voltages before being allowed to use Spice in any of it's versions. You should not n eed a simulation unless the thing is exceedingly complex, and most things a ren't. What happens at startup ? What happens at shutdown ? You should alre ady know this and the computer is just a tool to confirm it. You decided th e capacitor values, you designed the reset circuit. If it doesn't work in a simulation you should already know why.
I am not being hostile or trying to insult, thought I have been told I soun d that way sometimes. It is just it seems you got a bit more to learn. Work it out yourself before giving it to Spice, YOU designed it, YOU should kno w everything about it. Every bias on transistors, every time constant, ever ything period. Spice can be a nice tool to save you from wasting paper and then to confirm that the thing runs as YOU intended, but it cannot do it fo r you.
Bottom line if the unchanged circuit still runs in the simulation but the n ew and improved version does not, it has nothing to do with your computer.
They sat Madman Muntz used to walk through the engineering department and c ut components out of the prototypes the engineers were making. If it stoppe d working it was included in the final design. You might just have pulled a "Muntz" and removed something that was actually needed. But he did it one component at a time. If you remove a whole bunch of shit, why did you inclu de it in the first place ? Think back to WHY it is there.
Thank you for your reply. There is most likely no problem with the circuit, since it is from an LT datasheet. It just seems like the more I tinker with the sim, the less reliable the output is.
As was suggested by another, I will go through the netlist and see if I can spot what is happening. Might have something to do with running Wine Linux.
if I has a badly behaved sim, another test would be save it and re-load it in a new instance of ltspice and see if it is consistently bad or if it behaves better before looking for differences in the saved files.
--
This email has not been checked by half-arsed antivirus software
It runs fine in Wine on RHEL6, Fedora, and Debian--about one crash a month. Usually it says "can't start marching waves", at which point if you touch the plot window, down she goes. You can still save the simulation if you only touch the schematic window. So it's unlikely to be that.
Try poking around on the "SPICE" tab in the control panel. Turn on the 'alternate solver' for a start, and think about all the abs tolerances if you're running at unusually low currents.
As Phil Hobbs suggested, use "alternate solver". The basic solver is set up for show so that Mikey can claim fastest simulator... but it takes liberties and model simplifications in the process.
And go back to LTspice IV, XVII is _known_ to have bugs... join the LTspice List to follow all the whine. ...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
I tried that with my circuit, but it made no difference.
It was weird. The circuit was using an LT micropower comparator with reference and was designed to generate pulses when an external voltage exceeded a certain level. Quite straightforward, and it worked until I changed the resistance, but not the ratio, of a potential divider.
The thing that made it work again was the fix described above.
I've been using LTspice for years, albeit not intensively, and every so often it does something odd. Less often than it used to, that may be bug fixes or it may have subliminally trained me to avoid certain mistakes.
Sadly not. It would be great if all who could read SED had implicitly signed some sort of binding NDA, but until that happens, I can't post details of my client's IP, and without the details it would be pointless.
OK, that's sort of fatuous. But wouldn't it be great?
I'm pretty sure that numerical solvers depend upon the luckiness of their numbers being "approximately correct", or for that matter, incorrect just enough to be useful. With floating point (most often, double precision, I think?), the last couple bits are noisy, due to nonidealities in transcendental functions, and bit rounding after arithmetic operations.
Not having written SPICE myself, I'm just guessing here, but -- producing inversions of nearly-singular matrices is one of those ill-posed problems. The answer exists, but getting from A to B (or rather, to A^-1) is non-obvious. (A singular -- non-invertible -- matrix is the multivariable equivalent of "divide by zero".) If the rounding errors happen to coincide to a nearly-singular case, it will fail in a deterministic but non-obvious way. (And for that matter, it might be a combination of errors which isn't even near-singular, but just so happens to be an unfortunate combination for the algorithms used to compute it.)
In other words, in the region where the calculation fails, there are combinations of LSBs that work, and that do not work; it's not a sudden failure.
This does suggest that, if your circuit is failing, occasionally, it's still so far from well-behaved that it's probably a "wrong" circuit to begin with. But with nonlinear, time-dependent circuits, I don't think that's even a generally applicable case -- all circuits are "wrong", at some timestep or another, which is why variable timestep is used in the first place. Even with, for example, Jim's favorite continuous-derivatives function blocks. (It's just a matter of changing that fail-space from dense to sparse, and dodging the potholes.)
Hmm, now I wonder if there could be a rigorous definition to "fail space", between linear algebra and computer science.
Clive has not indicated if he's followed advice here and set Solver = Alternate?
One of my general rules of thumb is... if I experience repeated convergence issues... non-convergence or slow convergence, I'm doing something wrong, and I should revisit the pieces individually. ...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.