Well Jan,
You are both correct and incorrect
Correct in as much as you only have one huge file per circuit
Incorrect in as much as ( without the fix ) you always have one .raw file per design so if you have 50 designs @ 1.6gb / design that would gives 80gb scattered around !
Luckily the fix worked
You are both correct and incorrect
Correct in as much as you only have one huge file per circuit
Incorrect in as much as ( without the fix ) you always have one .raw file per design so if you have 50 designs @ 1.6gb / design that would gives 80gb scattered around !
Luckily the fix worked
For me this works, I have set this on a long time ago because I have a full harddisk.
LTSpice has 12 worker threads (I'm using alternative solver and 12 threads), how those get used seems to be based on:
1. model complexity and how the matrix optimiser can break the model in parallel
2. the optimiser I assume then looks at the number of CPUs and hardware needed (ie hyper threading vs real cores)
3. Then the system runs.
Here it's running 8 threads but the CPU is running at 500% (ie 5 cores). The machine is a mac mini 2019 which I deliberately built for modelling (LTspice, Octave, VMs and parallel development) - 3.2GHz 6-core i7 extended to 32GB ram. It has hyper threading enabled (although a security risk) to give 12 logical cores running 24/7 for the most part with a model running of some description.
I should add this is currently modelling a headphone valve amp - 12 triodes, passive low pass filters separate for each stage, a bridge rectifier and the transformer in stereo plus a 24V transformer and rectifier for bias control. Memory used 4GB but this rises to 10GB, with 100GB of data on the SSD.
Last edited:
If you know the model nodes (ie V(n001)) that you want, you can create a .save command and list only those that you want to save. The result is a very reduced raw file at the expense of not having values for nodes not specified.
Very useful for long runs that you want to simply test the stability of a specific sub-component for example or if you simply want the output FFT for an extended time.
I am thankful for your tutorial, help me tremendously.
The only bug I am really fighting with is currently that sometime LTspice starts to calulate even with a Max. timestep of 100n in .tran so slowly, that you watch it ps to calulate, while normally the results are there in 5-10 sec.
Sometimes this happens if transformer-ratios are odd numbers for example. But this happens not with .op or .AC ...and I do not now what triggers this behavior or which options to choose to get results always in 10 sec on average.
My circuit is not complictad: A SE Triode amp with teo 801A and a 845 all IT coupled.
The only bug I am really fighting with is currently that sometime LTspice starts to calulate even with a Max. timestep of 100n in .tran so slowly, that you watch it ps to calulate, while normally the results are there in 5-10 sec.
Sometimes this happens if transformer-ratios are odd numbers for example. But this happens not with .op or .AC ...and I do not now what triggers this behavior or which options to choose to get results always in 10 sec on average.
My circuit is not complictad: A SE Triode amp with teo 801A and a 845 all IT coupled.
This is a well known issue and not a real bug. And it happens with very basic circuits, preferrably with "ideal" components. No matter how you set the max timestep, LTSpice reduces the timestep sometimes down to femto-seconds resulting in enormous execution times. Avoid any ideal parts: Voltage sources, coils and caps should have some tiny series resistance etc....
I guess the tube model creates sharp corners in the transfer function, i.e the
transfer function cannot be differentiated or produces huge values when trying that.
Having very small and very large time constants in the circuit at the same time
aggravates that.
Gerhard
Thanks for all the hints...try to apply some...like 1R in each voltage source and 1k grid stoppers, realistic R in the windings, but no success...with tran still ps calculation...
here is the schematic
845-amp — ImgBB
here is the schematic
845-amp — ImgBB
Last edited:
OK, by trial and error I found if I change in the first transformer the coupling factor from 1 to 0.9998, we are in reasonable ms calc efforts, so after 10sec we have results.
If I do this with the other transformer as well, I have wild oscillations/motorboating. If I change that factor to 0.9999 in the first xformer, we are still in ps, going to 0.999 again ps. It must be the value of 0.9998. And it must be only in the first transformer or it will not work.
All the other things not needed, so gridstoppers , 1R in the voltage sources are out.
Bizarre.
If I do this with the other transformer as well, I have wild oscillations/motorboating. If I change that factor to 0.9999 in the first xformer, we are still in ps, going to 0.999 again ps. It must be the value of 0.9998. And it must be only in the first transformer or it will not work.
All the other things not needed, so gridstoppers , 1R in the voltage sources are out.
Bizarre.
Next bizarre thing: This behavior is dependent on the level of the AC-input. WIth certain voltages I am back to ps, other ns and others ms calculations....and we do not talk big differences...it is sometimes just the next digit you should add or erase. Magnitude stays the same.
Same with Voltage Sources...I just tried a 211 as a driver with 600V...ps calcs...with 605V...normal ms cals...
Same with negative bias Voltage sources...-35V...ps...-34V...ms
Same with Voltage Sources...I just tried a 211 as a driver with 600V...ps calcs...with 605V...normal ms cals...
Same with negative bias Voltage sources...-35V...ps...-34V...ms
Last edited:
Probably it depends upon whether you hit the sharp corners of the approximated
tube transfer function or not. Show the models.
Gerhard
I have seen similar stuff with my high-voltage amplifier. Use 12.7k on a resistor, get a timestep error, use 12.8k, all is well. Same with input voltage as said above, 1.35V is OK, 1.45V error.
The good news is, if you have the error, slightly changing a value randomly may get you out of it ;-)
I thought it was the high supply (2.1kV) in my design, but apparently not.
Jan
The good news is, if you have the error, slightly changing a value randomly may get you out of it ;-)
I thought it was the high supply (2.1kV) in my design, but apparently not.
Jan
OK...so, its a bug and we found the same workaround. I can live with that, I was just wondering if this is due to my beginner skills and usage error on my side or something else. When Jan is coming to the same conclusion, that is good enough for me. Thanks a lot to all.
Next thing I will crosscheck is how good the tube models actual work when you use a power DHT like a 211 as a driver...I used the 211 model from Duncan and from Github and both give me easly 5% distortion while a 801A is in the 0.02% range...which surprises me as I curvetraced the 211 and the curves look extremly linear from 15mA onwards...so I will generate a low voltage, low current model from the measured curves up to 100mA-600V (an area which you typically dont find detailed enough in the datasheets) and rerun the simulation...
Next thing I will crosscheck is how good the tube models actual work when you use a power DHT like a 211 as a driver...I used the 211 model from Duncan and from Github and both give me easly 5% distortion while a 801A is in the 0.02% range...which surprises me as I curvetraced the 211 and the curves look extremly linear from 15mA onwards...so I will generate a low voltage, low current model from the measured curves up to 100mA-600V (an area which you typically dont find detailed enough in the datasheets) and rerun the simulation...
Last edited: