- Joined Mar 1, 2015
Seems likelyWell, I'm no LTspice expert, nor am I one of the people that helped code it. But in my limited experience, the sort of results you've been getting are usually the consequence of imperfect numerical analysis techniques. They're caused, for instance, by iterations in which divisions are performed by a number that is too close to zero, or by the use of floating point variables in the code that do not have enough resolution to obtain an accurate result.
It might be, for instance (and most probably), that the software is internally using 32 bit numbers throughout the code, and that just won't cut it when performing calculations in extreme situations, like your circuit seems to pose.
Maybe (and this is mere speculation from my part) if the program were to be re-compiled to run in a 64 bit environment (with its internal variables also updated to make use of the whole spectrum of the hardware available to the OS) the result of your simulation would be very different.
FWIW In my (admittedly limited) experience with said simulator, when LtSpice 'stumbles', ground reference seems to figure into 'the mix' -- I have to wonder, for instance, if the trouble with my circuit is down to a condition whereby the instantaneous bias on a diode (or diodes) momentarily precludes an effective ground path? --- While I've not explored this, it seems plausible considering the 'nodes' complained of in the error message (when it occurs) reference the diodes in the 'lower' doubler --- as you and @Aleph(0) suggest, perhaps it's merely a 'resolution' issue inherent to digital modeling of analog phenomena? --- Anyway, having 'taken five', as it were, my patience has been restored --- I genuinely wish to continue my pursuit of proficiency with LtSpice
What the hey! Even as it stands, it's far less annoying than OrCad's simulator - and they don't give that away!
Sincere thanks for your insight and assistance