Re: A different timestep issue

On Fri, Oct 01, 2021 at 08:20:40PM -0400, al davis wrote:
> > I don't know how exactly s_tr_swp.cc:292 got triggered (note that we use
> > an old version.), but it does not seem to require further action. It
> > only happened with tstep=tend/500.
> 
> Actually, it does require further action.

Perhaps I wasn't clear about the context. Please read: It only happened
with tend/500 *and* the broken models in gnucsator including the
unpatched bjt with area=0. There is no evidence for a problem with
s_tr_swp.cc.

In the meantime I have also fixed the use of the Qucs MOSFET, it has a
polarity "parameter" similar to BJT. The mos model does not have an area
parameter, and I once tried w (it doesn't work). But mfactor=0 works
everywhere I tried:

  mynmos #(.w(W), .m((1.+Type)*.5), .l(L), .temp(Temp)) n(d, g, s, b);
  mypmos #(.w(W), .m((1.-Type)*.5), .l(L), .temp(Temp)) p(d, g, s, b);

In my understanding, mfactor simply scales all conductance and current
contributions, here selecting the polarity following Qucs conventions.
Also, evaluation and time step control in the mos model seem to be
sufficiently forgiving about reverse voltages.

In principle, and generally, devices with mfactor=0 could be taken out
of the equation with more rigour. I expect more model selection and
"multiview" demands down the line -- patching or extending every single
model is not practical.

For example: load some_spice/d_bjt.so breaks BJT in Gnucsator. This is
bad, because (pug and play) using foreign models is useful. What are
the options?