Re: precalc_first

[al davis]

On Sat, 10 Apr 2021 13:50:31 +0200
Felix Salfelder <felix@salfelder.org> wrote:
> If it wasnt for the case below, why is precalc_first not done in expand?
> (Is it speed again?)

It's not speed.

When there is a sequence of analysis commands, expand is done only on
the first, precalc is done every time.

First time:
        precalc_first()
        expand() // and do other allocations, like the matrix
        precalc_last()

Next time:
        precalc_first()
        // expand already done, no need to do it again
        precalc_last()

See void SIM_DATA::init(CARD_LIST* scope).

See also:
http://gnucap.org/dokuwiki/doku.php/gnucap:manual:tech:plugins:devices:allocation_and_setup

It says =====================
Some values don't matter whether they are calculated before or after
structure is determined. It strictly doesn't matter whether they are in
precalc_first or precalc_last. By convention, evaluation of parameter
expressions goes in precalc_first, calculation of other values that are
done only once goes in precalc_last. 
============================

The convention is not followed as it should be.  The actual convention
seems to be (as I said in the other email) to prefer having only one,
or to prefer last for devices, (and correcting ...) to prefer first for
models.

Probably doing it as the wiki says is better, but it isn't that way.


> Omitting precalc_first does break print_test. But also final_default,
> e.g. mjsw in d_mos5. The substitution good->hard will only recover a few
> of them, and not sure if there is a workaround at all.

It isn't just "good" vs "hard".

print_test might be based on something other than that particular
parameter.

hard_value ... was explicitly set, not calculated, not default.

good_value ... The value (however it got there) is "good", suitable for
use.  A default value is probably a good value.

The use of print_test has to do with not printing parameter assignments
that are misleading or irrelevant.  It might be a bad idea.

It probably should be that always has_hard_value says to print, and
maybe some other test (the one there now) too.


> > So maybe precalc_first and precalc_last should not be disabled in
> > DEV_SUBCKT_PROTO.
> 
> Ok I tried (see git). Some remarks.
> 
> - It seems DEV_SUBCKT_PROTO::precalc_first must omit
>   DEV_SUBCKT::precalc_first, in order to avoid wrong values in the
>   parameter map. (attach_params side effects).

It should not hurt to call precalc more than once, except for
possible repeating warnings and wasted time.


> - The additional subckt()->precalc_first triggers a few extra "using
>   default" warnings. I expected some, but I see twice as many in
>   d_subckt.{7,8}.ckt.

Side effect of calling a particular precalc more than once, when only
once is really needed.


> - I cannot see the use for precalc_last there. precalc_last comes after
>   expand, and expand is already disabled. I did not touch it.

I think a different test would show that wherever first is needed, last
is also.