[Top][All Lists]
[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