On Sunday 07 May 2006 11:01, Cyril Giraudon wrote:
> > On Wednesday 03 May 2006 12:07, Cyril Giraudon wrote:
> >> I actually try to write a tclspice like tool in python
> >> (pyrex, numpy modules).
> al davis a écrit :
> > How about doing it for gnucap?
> >
> > Lots of people have written front-ends and wrappers for
> > Spice. Gnucap really needs something like that, and to
> > provide the functionality of "nutmeg".
> My idea is to write an object oriented python module, and I
> need a python module for my work.
>.............
> The issue is not writing a pure spice frontend but rather a
> pythonic spice tool (module).
>...........
> So the job is not technically easy with Gnucap. Spice is a
> better candidate for that purpose. I think.
I see... Something for work. I was hoping you were up for
making a real contribution to the gEDA project. I guess not.
Your decision makes sense for something you need for work, that
you want quickly, with minimum commitment. Today, gnucap is
changing rapidly, ngspice is stable. Given your goals (what I
think they are), I would probably make the same decision.
If you were writing that general nutmeg type front end, I would
work with you, perhaps making changes, so you would not need to
modify the basic simulator at all. If what you need is a
general need, I would consider adding the features to the
official version. Priorities are usually determined by what
people ask for. The idea of the "bazaar" development model is
that lots of people each have some piece. Each piece has its
owner. The model where lots of people hack the same code is
better called "the street".
> The issue is not writing a pure spice frontend but rather a
> pythonic spice tool (module).
> We can see the simulator has to handle several circuits at a
> time. 2 solution :
> - The simulation can natively handle several circuits
> - The simulation is already object oriented and one can
> instanciate more than one circuit : each circuit owns its
> namespace (matrices, results vectors)
Gnucap almost does. I have been planning to complete the work,
so it really does, but so far nobody else has asked for it.
For now, you can fake it with subcircuits. Just define a
subcircuit for each one you want. In the root circuit,
instantiate one of each. This method is actually more
efficient and more flexible because you can instantiate with
parameters, and the simulator will optimize storage. Gnucap's
solver is smart enough to not calculate the one you don't drive
or probe. This trick would give you poor performance in Spice,
because it uses an all-or-nothing approach to solving the
matrix.
> I've tried to study and understand gnucap sources. Gnucap was
> the first simulator I thougth about : Pure C++ program, 8000
> lines of code (I think), compiles very well.
> Gnucap is written in C++ so I wished each circuit was a class
> instance with its proprieties and methods (own resolution
> matrices, ...) But it is not the way gnucap is coded, gnucap
> is not oriented "library".
I have been planning to change that, but there are other higher
priorities. There isn't much to change.
> There are a lot of global
> variables that could be local to a simulation.
About 5. More are static in a class, which is done so
parameters are kept from run to run. Making them non-static
would split them like you want, but it would no longer share
settings between runs.
> So the only
> thing Gnucap permits is wrapping its interpreter and gives
> the capability to use gnucap inside the python interpreter
> (it's already a good thing).
> Then I believe Gnucap doesn't save the nodes values when a
> simulation runs, Gnucap writes currents, tensions in a file
> or in the console but doesn't save them into the memory in
> order to retrieve them. So converting vectors into numpy
> arrays is not easy.
It doesn't save them as vectors because it is a bad idea. Spice
saves all the voltages (no currents except the ones that can
masquerade as voltages), which is one of the reasons the
performance is so poor for large circuits.
When I do a transient analysis, node voltages are rarely what I
really want to see. What I usually want to see are assorted
other data, such as voltage across some device, a power
waveform, transconductance vs time. Spice doesn't provide this
directly, so most users plot node voltages, then derive or
estimate the other curve based on the node voltages.
The reason Spice does it the way it does goes back to the much
less capable computers 30 years ago. The program was organized
into several overlays. Processing was organized so it would
run one overlay generating some data, swap it out and run
another overlay, then run another based on different data.
Readin was one overlay. Preprocessing another. The actual
simulation loop another. Data processing and output another.
The voltage arrays were a necessary part of managing these
overlays. I am referring to the original Fortran/Ratfor/M4
version of Spice.
Spice3 kept some of that, reducing it to two. "Spice"
and "nutmeg". Eventually they merged and the big storage
became a burden but by then the creators were moving on.
Looking at some of the newer commercial and in-house simulators,
the ones that use the two-part architecture put a lot more in
the interpreted part. For example, one of them has the
simulator core in C++ and interface in TCL. The simulator core
does one iteration at a time. The sweeping and iteration
control is all done in TCL. It uses the gnucap approach where
you select the probes first, which can be anything, not just
voltages, which are sent back to the TCL code in vectors, one
vector for each time point.
> Spice is not written with an object oriented language but
> offers an "object oriented approach" :
Sort of. Actually it violates encapsulation often enough to
lose most of the advantages of an object oriented approach.
> A struct instance for
> a circuit. All struct instances references in ft_circuits...
> Nodes current and tension are stocked during the simulation.
> The conversion into numpy array needed only a 30 lines
> functions reusing native spice function.
It seems to me it shouldn't take that many lines. "5" seems
more like it to me.
> Yes Gnucap can clean its memory, but Gnucap handle only one
> circuit at a time. Resolution matrices are deleted then
> re-allocated so it's not possible the swap between circuit
> without a lot of work.
I hope Spice doesn't keep the matrices around. The matrices are
really a scratch area, where intermediate values are stored.
There is nothing there that is of use externally. Actually,
they are completely replaced every iteration. The matrix ("A"
matrix) is built as models are evaluated, then an LU
decomposition is performed with the result overwriting the
matrix. Keeping the memory between iterations is only for
efficiency. No data is shared here.
Gnucap actually keeps more than Spice, because the LU is stored
separately from the "A" matrix. That way it isn't necessary to
rebuild the "A" matrix every iteration, or to solve the whole
thing every time. It is managed as a single unit, but actually
each subcircuit is solved separately, and sometimes subcircuits
can share storage. By managing it together, even if circuit
blocks may seem unrelated, there can be optimizations that
wouldn't be possible otherwise.
This has nothing to do with ability to store several circuits at
the same time. Spice only lets you manipulate one at a time,
so I wonder what the point is.
> >> More over, it seems that the model name in a .cir file
> >> can't contain ('/', '+', '-').
> >> What are the rules for models name ?
> >
> > I think it is letters, numbers, and underscore. Mostly not
> > case sensitive. Actually, the rule is that it is not case
> > sensitive, but there are occasional surprises, like the FAT
> > file system. Model names are supposed to start with a
> > letter, but there are occasions where this is not enforced.
>
> In fact, I've asked this question because I've tried to use
> PSpice diode model in ngspice, and ngspice failed reading the
> lib, ngspice stuck on name model like "ABC12345/-67". It was
> with a win XP machine and ngspice rework 17 compiled with
> mingw.
>
> Libraries are perhaps rewritten (by PSpice) before being read
> by the simulator ? Or the simulator is radicaly different ?
PSpice is a Spice-2 derivative. The original was simply Spice-2
compiled on a PC, with a minor hack to put reinstate the
overlays. The original user interface was worse than the free
version. The original was batch mode only. With the original
PSpice, you had to kick it a few times. Then put it on a
copy-protected disk, and make a crippled version for academics.
In a year or so, home computers became big enough to run Spice
without the hacks, but by then the academics were hooked, never
to return.
Eventually, they rewrote it in C, but they kept the file formats
for both input and output. Even today, if you look at the
actual simulator core output, it is in the old Spice-2 format
complete with headers and page feeds. Over the years, they
have added a lot to it, but it still has closer ties to Spice-2
than 3.
Regarding model names, and what characters are allowed ....
Whether +-/*[] are allowed is a simple change, that says
nothing about what goes on inside. If those characters are
common in published models, ngspice and gnucap should both
change to accommodate them.
