help-gnucap
[Top][All Lists]
Advanced

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

[Help-gnucap] Re: [Gnucap-devel] very large pure linear circuits


From: walter steffè
Subject: [Help-gnucap] Re: [Gnucap-devel] very large pure linear circuits
Date: Fri, 21 Oct 2005 09:45:28 +0200
User-agent: KMail/1.4.3

Dear Al Davis

The present message is related to my previous message sent to the 
''gnucap-devel'' list and to your reply (thanks for it). I was not able to 
post it on the same list so I am trying with the ''help-gnucap'' list which 
probably is more appropriate for this topic.


On Tuesday 18 October 2005 18:56, Al Davis wrote:

>
> Have you benchmarked it as it is?  It is a lot faster than Spice
> for that kind of circuit.  The biggest circuit in my test suite
> is about 35000 nodes.  When the options are set for speed, it
> takes about 15 seconds on a 850 MHz AMD.  It scales roughly
> linearly.  "A few hours" is very slow.  You can do better.
>

yes I have benchmarked it and here is the gnucap output:

/**************************************************************************
Cube Impedence
cube.ckt
time=    0.00
time=    0.20
time=   89.37
Gnucap   System status
command      --------  last  --------    --------  total  --------
               user      sys    total       user      sys    total
       get     2.53     0.07     2.60       2.53     0.07     2.60
        op     0.00     0.00     0.00       0.00     0.00     0.00
        dc     0.00     0.00     0.00       0.00     0.00     0.00
      tran     0.00     0.00     0.00       0.00     0.00     0.00
   fourier     0.00     0.00     0.00       0.00     0.00     0.00
        ac    89.26     0.11    89.37      89.26     0.11    89.37
function     --------  last  --------    --------  total  --------
               user      sys    total       user      sys    total
     setup     0.01    -0.00     0.01       0.01    -0.00     0.01
     order    -0.00    -0.00    -0.00      -0.00    -0.00    -0.00
function     --------  last  --------    --------  total  --------
               user      sys    total       user      sys    total
   advance     0.00     0.00     0.00       0.00     0.00     0.00
  evaluate     0.00     0.00     0.00       0.00     0.00     0.00
      load    13.88     0.01    13.89      13.88     0.01    13.89
        lu    72.01     0.03    72.04      72.01     0.03    72.04
      back     2.28     0.01     2.29       2.28     0.01     2.29
    review     0.00     0.00     0.00       0.00     0.00     0.00
    accept     0.00     0.00     0.00       0.00     0.00     0.00
    output     1.18     0.06     1.24       1.18     0.06     1.24
  overhead    -0.09     0.00    -0.09      -0.09     0.00    -0.09
      aux1     0.00     0.00     0.00       0.00     0.00     0.00
      aux2     0.00     0.00     0.00       0.00     0.00     0.00
      aux3     0.00     0.00     0.00       0.00     0.00     0.00
     total    89.26     0.11    89.37      89.26     0.11    89.37
iterations: op=0, dc=0, tran=0, fourier=0, total=746
transient timesteps: accepted=0, rejected=0, total=0
nodes: user=264, subckt=116, model=0, total=380
devices: diodes=0, bjts=0, mosfets=0, gates=0, subckts=7
commons: diodes=0, bjts=0, mosfets=0, gates=0, subckts=4
models:  diodes=0, bjts=0, mosfets=0, gates=0, subckts=4
dctran density=58.1%, ac density=58.1%
************************************************************************/


The reported results are obtained on a pentium xeon 2 GHz and 1GB RAM.
I did not set the options for speed because I were nor aware of them.
In the annexes you will find the input files of this benchmark.
I can confirm that gnucap is a lot faster than (the original) Spice for that 
kind of circuit. In fact I had done a Spice benchmark a lot of time ago and 
it was much worse then the gnucap results.

As I have told in the present  simulatiions the number of nodes (380) is not 
large because the they are related to a single subdomain. Nevertheless the 
computation time is not small (90s) probably because the ``coupling matrix is 
allmost full'' (there are many voltage controlled current generators 
connecting the circuital elements). The matrix sparsity will come into play 
when I will form the global circuit which will include the subcircuits 
associated to many subdomains. Indeed in the global circuit only the 
subcircuits related to adjacient subdomain will be coupled.

>
> As it is now, when a circuit is purely linear, gnucap solves the
> big matrix only once.
>
Is it true also for the ac analisys?
It seems to me that the total time is proportional to the number of frequency 
points.


> If you are willing to give up some accuracy, a completely
> different method such as a moment-matching method, will give
> you huge speedup.
>

I hope to be able to deal with the exact solvers. A motivaton for this choice 
(apart from accuracy) is that I know that the traditional approach allows a 
fast computation of the responce sensitivity versus the variation of  ircuital 
parameters and this is of great importance for the circuit optimization.  May 
be that the same can be achieved also with the moment-matching method but I 
not sure of that and I do not know of any open software that implement this 
method. On the other side I have to say that my circuit is already an 
approximation and that the subdomain related subcircuits are synthetized 
starting from the moments sequence associated with the electromagnetic 
responce. So it could be that going back to the moments for the simulation of 
global circuit is a good way to proceed (if I can find an available moments 
based code that is able to analyze my circuit).

In your reply you have introduced many other points and to me it is not clear 
which are the most important to improve the simuation of my circuit (node 
ordering, iterations related to the nonlinearity, memory usage...). May you 
please help me to explain the time figures. I see that the most of the time 
is used by ''lu'' but I think that 72s for the lu decomposition of a 380x380 
matrix is a long time (if it is done only once).


Best regards
Walter Steffe

Attachment: cube.ckt
Description: Text document

Attachment: cube132.ana
Description: Text document


reply via email to

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