gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] Accessing Matrix


From: al davis
Subject: Re: [Gnucap-devel] Accessing Matrix
Date: Tue, 16 Jul 2013 19:53:33 -0400
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

On Tuesday 16 July 2013, Rishabh Yadav wrote:
> I want to access the matrix values in the code.How can this
> be achieved?

For everyone else .. the reason Rishabh is asking is to 
implement the spice-compatible "mrdump" command, as part of the 
summer of code project.

The matrices (there are more than one) are part of the analysis 
command plugins.  The matrix class is defined in m_matrix.h .  
The matrix instances are allocated as part of a SIM_DATA, which 
is pointed to by _sim, a static in e_base, so it is available 
almost everywhere.

Side note .. naming convention .. leading underscore on a name 
says that it is class member data, supposedly private or 
protected.  It was a convention we used at Bell Labs, and I 
stuck with it.

Three matrices of concern are:
_sim->_aa : DC-tran matrix, before LU decomposition
_sim->_lu : DC-tran matrix, after LU decomposition
These are from the most recent dc/op/tran step.
After an AC analysis, these still belong to the dc/op/tran that 
came before.
Both before and after are preserved, both available at all 
times.  I am not sure what Spice prints, but here it would be 
good to be able to see either.

_sim->_acx : AC matrix, both before and after LU decomposition.
When you see it, it will probably be "after" LU decomposition.
It is the matrix of the most recent AC step.

It is a sparse matrix, so only the meaningful parts are 
allocated.

From the comments in m_matrix.h:
============================
 * individual element access ...
 * 5 access functions are provided.
 * All return lvalues (references to the actual entry).
 * All take 2 args, row and column.  They differ in speed and 
generality.
 * Since they are used in equations, they all have 1 letter 
names.
 * s(r,c) -- "safe" -- most general case, with bounds checking
 *      if completely out of bounds, returns trash
 *      if in the matrix but out of band, returns a reference to 
zero
 *      Changing it will corrupt the matrix.
 *      All others have no bounds checking.
 * m(r,c) -- "matrix" -- known to be within the allocated band
 * u(r,c) -- "upper" -- known to be in the upper triangle. 
(c>=r)
 * l(r,c) -- "lower" -- known to be in the lower triangle. 
(r>=c)
 * d(r,c) -- "diagonal" -- known to be on the diagonal. (r==c)
 * Using s() will always work, but will be slower than the other 
methods.
 * You should use the most restricted function that you know is 
correct.
============================
In this case, you will need (at least initially) the most 
general form which is "s(r,c)".

You will need to modify m_matrix.h to make it available to you.  
Since the "s" access is not used anywhere else, it is commented 
out.  You need to uncomment it and make it public.

It says untested, but actually it was tested informally long 
ago.





reply via email to

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