[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnucap] computing time

From: al davis
Subject: Re: [Help-gnucap] computing time
Date: Thu, 3 Jan 2013 22:39:38 -0500
User-agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )

On Wednesday 02 January 2013, Romain GAILLETON wrote:
> Before consider the following questions, you have to know
> that we don’t  care of the accuracy of the voltage
> calculated. We are working on a 110V scheme and we just want
> to know if the wire are undervoltage or not (the voltage are
> binarize by another application).
> I would like to ask the several questions:

> 1.      Which parameters can we use for reduce this computing
> time? 

The defaults are intended for the usual IC-analog circuits.  If 
you are doing something different, you may want to change them.

Reltol is relative, so probably ok as is.

abstol, vntol are absolute.  You might want tolerances that 
might seem big to otherwise ...  how about vntol=1 volt?  or 

Is there feedback in your circuit?

Is it linear except for the switches?

Really a POWER circuit .. 

vfloor= 1.f 
voltage floor .. try 1 volt?

roundofftol= 100.f
100 femptamps???  try .001 (1 milliamp)

gmin= 1.p  
1 picomho,  10^12 ohms.
I get the feeling 100k is big for you .
try gmin=1e-6

short= 10.u  reltol= 0.001  

abstol= 1.p  
controls currents to 1 picoamp ..  .001 amps good enough??

vntol= 1.u  
controls voltage to 1 microvolt   ..  1 volt good enough???

chgtol= 10.f  
controls charge to 10 femtocoulombs ..
ignored if you are using Euler.

bypasstol= 0.1  loadtol= 0.1
How aggressive to bypass.
It probably doesn't matter with no semiconductors.
0.1 means 10x tighter than final tolerance.

* iteration limiting and heuristics
.options  itl1=100  itl2=50  itl3=6  itl4=20  itl5=0  itl6=5000  
itl7=1  itl8=99  
These are limits, when to give up.  You shouldn't be getting 
convergence failures with this circuit.  Probably no more than 3 
iterations on each step anyway.

Number of extra check iterations to do to insure accuracy, to 
protect against false convergence.  try itermin=0.

vmax= 5.  vmin=-5.  
Convergence heuristics .. probably doesn't matter here, but it 
is best to make these numbers a little bigger than anything you 
expect to see.  vmax=150 vmin=-150 ????

dampmax= 1.  dampmin= 0.5  dampstrategy=0
These only come in when having trouble converging.  Mostly it is 
a way of upsetting Newton loops to get out of limit cycles.

dtmin= 1.p  
The minimum time step is 1 picosecond.
.001 seconds good enough for you??

dtratio= 1.G  trstepgrow= 1.E+99  trstephold= 1.E+99  
trstepshrink= 2.  trreject= 0.5  

Adjust stepping based on cubic splines.
probably best left alone.

trstepcoef1= 0.25  trstepcoef2= 0.04166667  trstepcoef3= 
these best left alone.

> 2.      Is there an option which would allow Gnucap to
> recalculate only the nodes where the voltage have changed?

It sort of does now.

> 3.      Is there an option which could allow us to send to
> the output only  the nodes which are in a range?
> Example: “print tran v(nodes) “  Which nodes are between 0 to
> 4000

Node names are strings.   Wildcards * and ? are supported.  With 
clever naming, selection can be very simple.

> 4.      Is the time given by acct the real computing time?
(or the status command)


> 5.      Could it be possible to reduce the computing time
> under 500ms in  your opinion?

don't know ..

but look at what stat tells you ... where is it spending the 

add "trace all" to the tran command to see all steps.

add a probe "iter(0)" to show how many iterations on a step.

There is a problem with read-in time in the snapshot.  Adding a 
feature (in the function "find_looking_out") made it slow.  Need 
to change the search method.  If readin dominates, try an older 
version, or comment out the call to find_looking_out, if you 
don't need it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]