gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] Gnu cap src help


From: al davis
Subject: Re: [Gnucap-devel] Gnu cap src help
Date: Sat, 1 Sep 2012 12:07:32 -0400
User-agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )

> On Sat, Sep 01, 2012 at 01:03:45AM -0700, _griv wrote:
> > But i would be glad if you suggested me a way, if possible,
> > to get just the matrix that evaluate_models() creates. I
> > want it just befor LU decompostion takes place. Should i
> > change the code in order to get what i want or there is an
> > easier way or something already implemented?

evaluate_models() doesn't create a matrix.  It just evaluates 
the models.  For linear non-storage components like resistors it 
does nothing at all.

The procedure is different between AC and dctran.  AC does not 
evaluate models in a nonlinear sense.  It just uses the results 
from a previous dc/op/tran.

In dctran, you can think of evaluate_models as being 
"CARD_LIST::card_list.do_tr();".  The rest is either 
acceleration or accounting.  In AC, it simply is 
"CARD_LIST::card_list.do_ac();".  Again, this does not create 
the matrix.

Creation of the matrix happens next.  In dctran, that's 
"load_matrix()".  You can think of it as being in the simpler 
form "CARD_LIST::card_list.tr_load();".  The rest is either 
acceleration or accounting.  In AC, it simply is 
"CARD_LIST::card_list.ac_load();".

Now, you have a matrix, before LU decomposition takes place.

For the solve phase, AC and dctran differ again ..   

In AC, there is one matrix "acx".  LU overwrites the matrix in 
place.  The original matrix is not reused, so it is not stored.  
This is typical of LU solvers, and also the way Spice does it.

In dctran, there are two matrices "aa" and "lu".  LU does not 
overwrite the matrix.  The original matrix is preserved.  This 
allows further steps and iterations to use a selective trace 
algorithm to do partial solutions, while at all times giving the 
appearance that it did a full solution.

Looking again at evaluate_models and load_matrix.  In dctran, 
these functions will evaluate only the models that need to be 
re-evaluated, and load only the ones that changed, while giving 
the appearance that all were evaluated and loaded.  To make this 
work, "load" does not load the values, but rather loads the 
difference between the current and previous values, in effect 
unloading the previous value then loading the new one, but in a 
single step.

To access a particular entry in the matrix, there appear to be 5 
functions, but are actually 8.  (d, u, l, m, s).  The ones 
returning "T&" return lvalues.  The ones returning "T" return 
rvalues.  The compiler will automatically select based on 
whether an lvalue or rvalue is needed.  Both versions are needed 
because of C++ compile time "const" enforcement.  All of them 
are called identically.  You could always use the more general 
one, but it will be slower.  The less general ones exist to make 
it faster.

"s" .. safe access to anything. You could use this one anywhere, 
but it is slow.  It is commented out because gnucap doesn't use 
it anywhere, but left in because it could be used for testing or 
in the future.

"m" .. any valid matrix entry, with no bounds checking.  It will 
return garbage or segfault for out of bounds or any unallocated 
location.  Note that most of the matrix zeros are unallocated, 
and therefore will return garbage.  This is faster than "s" but 
slower than "d", "l", "u".

"l" .. known to be below or on the diagonal, no checking
"u" .. known to be above or on the diagonal, no checking

"d" .. known to be on the diagonal, no checking, fastest




reply via email to

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