Re: [Gnucap-devel] method and error (was: transient -- "trace" default)

[al davis]

On Saturday 11 January 2014, Felix Salfelder wrote:
> in combination, it seems to work best. consider
> d_switch_nro.3.ckt.
> 
> vanilla gnucap yields
> iterations: op=0, dc=0, tran=18028, fourier=0, total=26977
> transient timesteps: accepted=147, rejected=8802, total=8949
> 
> with my euler fallback i get
> iterations: op=0, dc=0, tran=425, fourier=0, total=573
> transient timesteps: accepted=148, rejected=0, total=148

Without seeing the code, I don't know what that means.

You could get a similar apparent fix by changing ITL1 to 99.

The rejections in this case are code 17, missed event.  
SWITCH_BASE::tr_review computed a next event in the past, 
because there was no event yet the state changed.

That is because of a DC convergence failure.  This circuit does 
not have a stable DC operating point so the convergence failure 
is the correct result.  For it to converge would be incorrect.

I think this case is an example of where it is appropriate to 
ignore time==0 in step control, like e_element does, because it 
gives bogus results.

Some of the test files are designed to fail.  If you "fix" it, 
it is necesary to ask if the fix really fixes something or if it 
just changes the test case so the test no longer tests what it 
is supposed to test.

If your euler fallback introduces a new step based on truncation 
error (code 6) first, absorbing the non-event state change, that 
would be the case.  It isn't fixed.  It's an arbitrary change 
that makes it so the concept being tested isn't being tested 
anymore.

Another test ...  if I add "skip 2" to the tran command, it's 
down to 4 rejections (code 16, truncation or curve fit error), 
none at the beginning.  Again, it doesn't really fix anything, 
just changes the test.