Re: Help-gnucap Digest, Vol 88, Issue 3

Hi,

So I tried your parameters and it seems to work pretty well now. The 
computing time is roughly divided by 8 which is nice ! Yet we need to 
improve it a little bit more.
We can reach the previous computing time (divided by 8) when we set 
dtmin=0.01 but after several actions on the different elements of the 
circuit, it seems like it induces a convergence issue (non-recoverable 
initial guess).
I tried to reduce the ratio RON/ROFF for my switches like I saw in a 
previous post but it increases the computing time (Currently RON=1E-5 
and ROFF=1E15). I finally set dtmin at 0.001 in order to prevent us from 
having this issue.
>>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 time?

95% of the computing times seem to come from the LU operation according 
to the "status" command.
I  am running Gnucap on Windows using the last available version (2009)
So I tried to run it on Linux using the 0.35 version but the 
improvement was not as good as expected.
We end up with 5% gain on the computing time using the same parameters 
you gave us earlier. Would you expect this result too ?

Thanks to everyone for the help


Le 2013-01-07 18:00, [email protected] a écrit :
> Send Help-gnucap mailing list submissions to
> 	[email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.gnu.org/mailman/listinfo/help-gnucap
> or, via email, send a message with subject or body 'help' to
> 	[email protected]
>
> You can reach the person managing the list at
> 	[email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Help-gnucap digest..."
>
>
> Today's Topics:
>
>    1. Re and more (Romain GAILLETON)
>    2. Re: Re and more (Felix Salfelder)
>
>
> 
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 07 Jan 2013 08:38:50 +0100
> From: Romain GAILLETON <[email protected]>
> To: <[email protected]>
> Subject: [Help-gnucap] Re and more
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi !
>
> First of all Thanks for your previous answers, i will test it as soon
> as possible.
>
> Some advised me to let gnucap choose its step size but I would like 
> to
> know how to let it do so because when I don't set the stepsize the 
> first
> time I use the command "tran" it doesn't work saying it misses the
> stepsize.
>
> Thanks again.
>
>
> Le 2013-01-04 18:00, [email protected] a ?crit?:
>> Send Help-gnucap mailing list submissions to
>> 	[email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	https://lists.gnu.org/mailman/listinfo/help-gnucap
>> or, via email, send a message with subject or body 'help' to
>> 	[email protected]
>>
>> You can reach the person managing the list at
>> 	[email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Help-gnucap digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: computing time (al davis)
>>
>>
>>
>> 
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 3 Jan 2013 22:39:38 -0500
>> From: al davis <[email protected]>
>> To: [email protected]
>> Subject: Re: [Help-gnucap] computing time
>> Message-ID: <[email protected]>
>> Content-Type: Text/Plain;  charset="utf-8"
>>
>> 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
>> more?
>>
>> 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.
>>
>> itermin=1
>> 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
>>
>> trsteporder=3
>> Adjust stepping based on cubic splines.
>> probably best left alone.
>>
>> trstepcoef1= 0.25  trstepcoef2= 0.04166667  trstepcoef3=
>> 0.005208333
>> 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)
>>
>> Yes.
>>
>>> 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
>> time?
>>
>> 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.
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Help-gnucap mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/help-gnucap
>>
>>
>> End of Help-gnucap Digest, Vol 88, Issue 2
>> ******************************************
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Jan 2013 12:15:52 +0100
> From: Felix Salfelder <[email protected]>
> To: [email protected]
> Subject: Re: [Help-gnucap] Re and more
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Jan 07, 2013 at 08:38:50AM +0100, Romain GAILLETON wrote:
>> Some advised me to let gnucap choose its step size but I would like
>> to know how to let it do so because when I don't set the stepsize
>> the first time I use the command "tran" it doesn't work saying it
>> misses the stepsize.
>
> Hi Romain.
>
> the stepsize passed to .tran is the printing stepsize. internally 
> gnucap
> computes more steps (all print steps and some more).
>
> to see all computed steps, type
> .tran 0 1 .1 trace=a
>
> invoked with
> .tran 0 1 1 trace=a
> gnucap does not compute extra steps just to print something.
>
> hth
> felix
>
>
>
> ------------------------------
>
> _______________________________________________
> Help-gnucap mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/help-gnucap
>
>
> End of Help-gnucap Digest, Vol 88, Issue 3
> ******************************************


_______________________________________________
Help-gnucap mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-gnucap