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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
