Re: faster queueing

On Wed, Feb 24, 2016 at 02:15:08AM -0500, al davis wrote:
> > using this list instead of the full list decreases tr simulation time by
> > a factor of almost two (eq4-9217.tran.ckt).
> 
> I am suspicious of this.  If the implementation is correct, the results
> would be exactly the same, including the same number of iterations, the
> same number of model evaluations.

they are. with a few exceptions. see [1] for what I did to -uf
(note that numerical noise is might be filtered out, on top of that).
constant components do no longer interfere with step control, hence i
sometimes get fewer iterations, in particular if the circuit it too
simple.

> I see a few things wrong.
> 
> Devices with storage may need evaluation even when constant, to
> accommodate step changes.

i do not understand. there's a conflict with my interpretation of
"constant". what does it really mean?

> tr_advance is needed, constant values or not.  
> tr_review is needed, constant values or not.

are there multiple sorts of "constant"? why would a constant resistor
require these? afaics, caps don't use is_constant().

> > the changes involve one uglyness, that i think you are already aware
> > of... the dc sweep pointer-hacks elements and sets them non-constant, so
> > they are queued. this non-const setting comes after the non-const queue
> > has been set up (too late). my current workaround adds these elements to
> > the evaluation queue of the top level circuit.
> 
> The whole dc sweep pointer hack is ugly.  With params, it shouldn't be
> needed any more, but I haven't had the time to do it.

indeed, in -uf there's a "precalc_last()" call after setup(cmd) in
s__init.cc... iirc due to some issues with temperature dependency. need
to recheck...

in the meantime, would adding q_hack be an option for you?

cheers
felix

[1] https://github.com/felix-salfelder/gnucap/commit/89bd39efd9f1b2b79ef86a81a4037aa920cc85a8