this device has a completely variable number of ports,
and those are not at all at the expected GENnodes[] place.
perhaps this can be worked around by saying it has zero ports,
together with special code in INP2..c
if this is really an "external" optional node,
then this must be moved up in the struct definition to match
position with the XXNames[] array, and to match usage via GENnode[]
if it is merly an "internal" node, which might be monitored via CKTfindBranch,
then it should be removed from the XXNames[] array, again to fit usage via GENnode[]
this is a "pin-pointer" commit,
pointing to places for source code verification
we have int Nodes in every device instance,
these are overlaid with struct GENinstance.GENnode[] and will be used
from there too.
the length entries and the XXnames[] arrays *must* fit this.
Thats done in CKTcrtElt() now,
and avoids overwritting private device internal Node variables,
which are expected to be initialised to zero (by TMALLOC)
otherwise node-numbering/matrix-index-numbering will break
FIXME, because removing all internal nodes is mandatory
the == 0 compares in the device setup routines are useless,
and even dangerous, because sometimes node names get copied, so that
the outcome of a previous setup will possibly prohibit a node from
being created (after a topology change due to "altered" paramers)
invoke CKTdltNNUM() in revers order of creation.
The guarding of the CKTdltNNum() invocations needed access to node numbers
which have already been killed. (HFETAdrainPrimeNode and HFETAsourcePrimeNode)
invoke CKTdltNNUM() in revers order of creation.
The guarding of the CKTdltNNum() invocations needed access to node numbers
which have already been killed. (MESAdrainPrimeNode and MESAsourcePrimeNode)
default is 2, maximum verbosity
option indverbosity=1
can be used to prevent check for
"incomplete set of couplings"
option indverbosity=0
can be used to avoid the check altogether
set indverbosity=INTEGER
or
.option indverbosity=INTEGER
works as well