Re: precalc_first

On Thu, 8 Apr 2021 00:10:04 +0200
Felix Salfelder <[email protected]> wrote:
> I don't fully understand the purpose and use of precalc_first.


It has to do with the interaction between precalc and expand, and
interaction between devices that use secondary calculations such as
current as input, such as mutual inductance and current controlled
sources.

It's all part of the setup of devices that happens at the beginning of
any analysis.

"precalc" does calculations, filling in default parameters, calculated
parameters, numeric data that remains constant through a simulation.
It does not do anything to structure.

"expand" sets up structure, expanding subcircuits, collapsing nodes,
adding nodes, etc.  It does not make any calculations.

There are two variants of "precalc" ....  "precalc_first" and
"precalc_last".  The difference is that "precalc_first" is called
before "expand", and "precalc_last" is called after "expand".

Calculations that may have an impact on expand (structure) must be
done in precalc_first.  Calculations that depend on how expansion was
done must be done in precalc_last.

For most of these calculations, it really doesn't matter whether they
are "first" or "last", so you could do it either way.  The usual basis
for the choice of where to put the calculation is to have either a
first or last, but not both, or to prefer last if there is no other
basis for choosing.

So, you might think the sequence is:

precalc_first()
expand()
precalc_last()

Due to what expand does, it doesn't quite work that way.  Parts of the
circuit do not exist until after expand() is done, so their
precalc_first would be missed.  In cases where there is hierarchy
(subckts), precalc_first would be missed because copies do not exist
until after expand, so precalc_first is called by subckt->expand rather
than directly.


On Thu, 8 Apr 2021 00:10:04 +0200
Felix Salfelder <[email protected]> wrote:
> In c_list.cc save_list  
> ...........
> ....  the list is missing some
> parameters.


That looks like a problem with print_test in the .model files, or the
generated code in XXXXXX::param_is_printable() .

save_list probably should not call precalc_first.  What about
precalc_last ? ..  or maybe it should.  print_test depends on it.

DEV_SUBCKT_PROTO is just being stored.  All behavior is disabled, so it
doesn't do something by just being there not instantiated.  I suppose
precalc doesn't hurt anything.  The something useful it could do is to
fill in the _v that print_test uses.  The other choice is to change
print_test in *.model to be (xx.has_hard_value) .. where xx is the name
of the parameter.

So maybe precalc_first and precalc_last should not be disabled in
DEV_SUBCKT_PROTO.