Re: gEDA-dev: Gnucap & python wrapper

[al davis <ad106-at-NOSPAMfreeelectron_dot_net>]

On Wednesday 27 September 2006 03:59, cyril giraudon wrote:
> I succeeded in wrappring gnucap CMD::cmdproc() method and
> controlling a simulation sequence. The issue I think of is the
> result ouput.  A user would like to run a simulation step  and
> then 

Why do you want to run single steps?  I think what you want is 
to run until a particular time, or maybe until something 
happens. I need to add something like a "break" command, 
like "alarm" but stops.  Remember .. it actually does some 
extra steps that you don't see.

> - get some values of the computed vectors;
> - set directly some values (controlled sources);
> - store values in python matrices/vectors;
> - apply transformations to the values before he reinjectes
> them;

"modify" ??

> - ...
>
> In the code, outputs are handled in the sweep method (for
> transient simulation) and at each iteration the output data
> method is executed. 
>
> The (tr, ac, dc, op) simulation are locale to the 
> CMD::(tr; ac; dc; op) method. So It's not possible to
> interrogate the simulation. 

What do you want?  It might be easy to add.

> So I tried to use static members.
> I wrapped PROBELIST and PROBE so AFTER the simulation
> (eq5-.tran.ckt) 

Gnucap doesn't save much. It is designed for big circuits for 
which saving everything would be prohibitive. Also, node
voltages are rarely what you actually need. Spice users usually 
ask for node voltages from which they can calculate what they 
really want. Gnucap can usually give you that directly.

> I do the following sequence :
>
> # from Pyton, free syntax, between C++ and Python :-)
> v5Probe = PROBE_LISTS::print[sTRAN].bag[0]
> If fact, I have added to PROBELIST two methods to get the
> PROBEs 
> (it's not important):
>  PROBELIST* next() {return this + 1;};

This is probably wrong.  When you have a pointer to an object, 
and know nothing else about it, it is rarely useful to 
increment it.  The next PROBELIST?  I don't know what that is.  
There might not even be a PROBELIST there.  

Pointers are the "goto"s of data.  Flags are the "assigned 
goto"s of data.  Either are dangerous, but sometimes we need 
them.

>  PROBE* getProbe(const int i) {return &(bag[i]);};

The actual form of the container "bag" is private.  For now, it 
is stored as a vector, but I could change that to, for example, 
a list.  Just one word is all it takes.  Even if it is a vector, 
the location may move, therefore addresses of members are not 
guaranteed.

Even so, you are selecting a PROBE by an index number.  Where do 
you get that number?  They have no significance and are not 
stored anywhere.  You don't even know what the range is.  For 
example, if there are 10 probes, they might be numbered 263 to 
272.  Actually, in this case, they do start at 0, but you can't 
count on it.  I never access them by number.

You need to return type PROBELIST::const_iterator. Dereferencing 
it will get you a PROBE.  Other operations will work correctly 
regardless of the underlying container type.

If you want to know more about containers and iterators in C++, 
please ask.  I think python has them too.

> python>print v5Probe.label()
> -> "v(5)"
> So, Probes are accessible.
> python>print v5Probe.value()
> segmentation fault.
>
> Why does this segmentation fault occur ? Matrices cleared ?

I can't tell without more information.

You should be compiling with the old build system, in debug mode 
("./configure.old" then "make debug")  You might get more debug 
info than you want.  The "untested", "itested" and "trace" 
macros can give you lots of information.  With these, you 
should be able to find it fast.  Maybe I should make a post 
explaining them.  I think the whole gEDA project and others 
could benefit by using them.

> Is it possible to reach probes value after the run ?

No.  You need to store them as they come out.  Spice stores 
this (in a file), but only gives you very limited information.


You should subscribe to the gnucap developer mailing list:

gnucap-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnucap-devel



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev