if r == -1, no repetition done.
if r == 0, repeat forever.
if r == xx, repeat from time xx to last time point given.
If r is omitted, like r == -1 no rpetition done.
This patch itself is not valid until all invokers of DEVdestroy()
(currently this is CKTdestroy() exclusively)
are rewritten to invoke DEVmodDelete() and DEVdelete()
and use a more robust test for local node numbers.
That is, transform this pattern :
if (here->Node && ...) {
CKTdltNNum(ckt, here->Node);
here->Node = 0;
}
into this :
if (here->Node > 0 && ...)
CKTdltNNum(ckt, here->Node);
here->Node = 0;
The change of "!= 0" ==> "> 0" accounts for rare cases where "Node"
might have been set to -1, (meaning "unconnected")
The unconditional execution of the zero assignment is for those cases
where "Node" might have been assigned to some external or other local Node.
If so, the variable would not be set to zero, confusing the "guarding" if's
in the corresponding XXXsetup() routine.
The Pattern to follow is:
1) unset and delete *all* local Nodes in XXXunsetup()
2) allocate all of them again in a re-invocation of XXXsetup(),
exactly the same way as in the very first invocation.
for almost all other external nodes (notable exception "txl")
src/spicelib/devices/*/*def*.h, declare external node variables const
1) The compiler shall emit an error message if we still mess around
with external node numbers.
2) To mark which elements of the instance struct are meant to be set
externally when parsing the netlist
These "external" node variables are exclusively set via the
overlay struct GENinstance, member GENnode[]
We shall not mess around with these "external" node variables
because it would get rather difficult to avoid bugs considering
re-invocation of the XXXsetup() routine.
This gets interesting for devices with optional ports,
which get copied around depending on the amount of connected ports.
Avoid NAN error when executing "show all"
Thanks to Sergii Baitala, who reported this in
#299 Shared ngspice: missed VSRC_EXTERNAL handler in VSRCask
http://sourceforge.net/p/ngspice/bugs/299/
Bug report due to Hartmut Henkel in
>> [Ngspice-users] Noise analysis depends on ac parameter
The noise analysis internally depends on an ac analysis
to derive "inoise" from "onoise"
("onoise" is multiplied with the inverse ac gain from input to output)
This AC analysis used all the given ac magnitudes for all vsrc/isrc
devices in the deck.
This fix overrides all ac magnitudes with zero,
except for the given input device,
whose magnitude is set to one.