However, it seems that the transient simulation get stuck in a time point, just like the following shows.
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
thank you in advance,
An
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This circuit forces very small timesteps (200ps) relative to its
total simulation interval (100us).
It does not run with other simulators, e.g. LTspice + normal
solver (64bit floats). It does run with LTspice's alternative
solver (80-bits).
What signal needs the 200ps max step? What would be an insightful
plot/print statement?
-marcel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem goes away when the GEAR method is selected and TRTOL is set to a reasonable value. After this, TSTEP does not have to be 200ps for detailed results.
BTW: there is only something interesting to see when the UIC option is added (e.g. the inrush current is an 80A spike). I cut the total simulation span because the initial transient dies out in about 10us. You should't have to to wait for a >4 GByte raw file with zeros :-) The simulation takes ~360ms in total after these changes.
Hi, all,
I am using ngspice to do transient simulation.
However, it seems that the transient simulation get stuck in a time point, just like the following shows.
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
Reference value : 4.25000e-06
thank you in advance,
An
This can't be debugged without a circuit and control file if used.
Can you please post a test case that demonstrates your issue, keeping it as
simple as possible?
--
Kind regards,
Justin Fisher.
Sent from my phone.
I am sorry. The circuit is a little large.
Last edit: Robert Larice 2017-05-18
Dear An,
Could you post important text between
"~~~" and "~~~" delimiter strings?
... or attach a file with the netlist.
The Forum formats messages in a
way that causes all kind of trouble.
-marcel
This circuit forces very small timesteps (200ps) relative to its
total simulation interval (100us).
It does not run with other simulators, e.g. LTspice + normal
solver (64bit floats). It does run with LTspice's alternative
solver (80-bits).
What signal needs the 200ps max step? What would be an insightful
plot/print statement?
-marcel
The problem goes away when the GEAR method is selected and TRTOL is set to a reasonable value. After this, TSTEP does not have to be 200ps for detailed results.
BTW: there is only something interesting to see when the UIC option is added (e.g. the inrush current is an 80A spike). I cut the total simulation span because the initial transient dies out in about 10us. You should't have to to wait for a >4 GByte raw file with zeros :-) The simulation takes ~360ms in total after these changes.
-marcel
Last edit: marcel hendrix 2017-05-18
Hi, Marcel,
Thank you so much. The problem is solved.
I am doing a power delievery network analysis using ngspice.
Auctually, I wrote a c problem to call the ngspice shared library and change the current load very 10ns.
Thank you again,
An