gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Felix Salfelder
Subject: Re: [Gnucap-devel] method and error (was: transient -- "trace" default)
Date: Sun, 12 Jan 2014 12:09:12 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Sun, Jan 12, 2014 at 12:12:08AM -0500, al davis wrote:
> 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.

yes, i picked the wrong example.

> 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.

true, my reduced iteration number goes back to

    if (_time_by_ambiguous_event < newtime) {
      newtime = _time_by_ambiguous_event;
      new_dt = _time_by_ambiguous_event - time1;                 (A)
      new_control = scAMBEVENT;
    }

in the initial step handler in TRANSIENT::next(). there seems to be no
connection to discontinuity handling. i will try find a real example
within the test suite...

> 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.

this is interesting. otoh, if bogus results lead to smaller steps, is that
really wrong?

> 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.

i agree. looking closer, i am getting (in switch.nro.3)

#Time       V(1)       r(SW1)     iter(0)    input(SW1) timef(SW1) control(0)
did not converge
 0.         999.99     10.Meg     101.       100.u      0.         1.        
 2.p        100.u      1.         2.         999.99     2.p        7.        
 4.p        100.1u     10.Meg     2.         100.u      99.498u    7.        
 6.p        100.3u     10.Meg     2.         100.1u     49.749u    6.        
 8.p        100.5u     10.Meg     2.         100.3u     49.749u    6.        
 10.p       100.7u     10.Meg     2.         100.5u     49.749u    6.        
 294.13n    0.029512   10.Meg     3.         100.7u     49.75u     6.        
 3.5294u    0.35298    10.Meg     3.         0.029512   49.758u    6.        
 10.u       0.9996     10.Meg     3.         0.35298    49.781u    1.        

instead of the missed event in

#Time       V(1)       r(SW1)     iter(0)    input(SW1) timef(SW1) control(0)
did not converge
 0.         999.99     10.Meg     101.       100.u      0.         1.        
 80.32n     100.u      1.         17.605K    999.99     80.318n    17.       
 80.322n    100.1u     10.Meg     2.         100.u      99.578u    7.       

(which is only a side effect, actually i added (A) to fix the sine source
sampling close to time=0).

thanks
felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]