gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] discontinuities. was: traces


From: al davis
Subject: Re: [Gnucap-devel] discontinuities. was: traces
Date: Wed, 15 Jan 2014 20:17:01 -0500
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

On Monday 13 January 2014, Felix Salfelder wrote:
> however, it is no surprise, that an euler in the right spot
> reduces ringing. the difficult part is when to do a
> fallback. i have decided to fallback if an adjacent node
> knows about a discontinuity. the current implementation is
> experimental and probably still buggy. but results are
> clearly visible.

I ran the test case with my pulse patch, which has even better results.
This is vanilla gnucap plus the pulse patch.

#Time       v(n1)      v(n2)      i(r1)      method(c1) control(0)
 0.         0.         0.         0.         2.         1.        
 0.1        0.         0.         0.         2.         9.        
...
 0.5        0.         0.         0.         2.         6.        
 1.         0.         0.         0.         2.         7.        
 1.         5.u        4.995n     4.995n     2.         7.        
 1.001      0.99998    0.98038    19.603u    2.         7.        
 1.001      1.         0.98042    19.579u    2.         7.        
 1.0011     1.         1.0145    -14.538u    2.         16.       
 1.0012     1.         0.99008    9.9183u    2.         6.        
 1.0013     1.         1.0054    -5.4414u    2.         6.        
 1.0014     1.         0.99701    2.9853u    2.         6.        
 1.0014     1.         1.0016    -1.6378u    2.         6.        
 1.0015     1.         0.9991     898.54n    2.         6.        
 1.0016     1.         1.0006    -622.89n    2.         6.        
 1.0017     1.         0.99957    431.8n     2.         6.        
 1.002      1.         1.0004    -359.34n    2.         6.        
 1.0023     1.         0.99968    320.3n     2.         6.        
 1.0029     1.         1.0003    -298.76n    2.         6.        
 1.0039     1.         0.99971    287.77n    2.         6.        
 1.0058     1.         1.0003    -281.68n    2.         6.        
 1.0092     1.         0.99972    278.36n    2.         6.        
 1.0153     1.         1.0003    -276.55n    2.         6.        
 1.0264     1.         0.99972    275.55n    2.         6.        
 1.0466     1.         1.0003    -275.n      2.         6.        
 1.0831     1.         0.99973    274.71n    2.         6.        
 1.1497     1.         1.0003    -274.54n    2.         6.        
 1.2693     1.         0.99973    274.45n    2.         6.        
 1.4875     1.         1.0003    -274.4n     2.         6.        
 1.8745     1.         0.99973    274.37n    2.         6.        
 2.5516     1.         1.0003    -274.35n    2.         6.        
 3.793      1.         0.99973    274.34n    2.         6.        
 5.862      1.         1.0003    -274.34n    2.         6.        
 7.931      1.         0.99973    274.33n    2.         6.        
 10.        1.         1.0003    -274.33n    2.         1.        
Gnucap   System status
iterations: op=0, dc=0, tran=124, fourier=0, total=163
transient timesteps: accepted=37, rejected=2, total=39
nodes: user=2, subckt=0, model=0, total=2
dctran density=100.0%, ac density=100.0%

It looks better with more digits (numdgt).

The two steps at 1 and at 1.001 are actually minus and plus
epsilon, exactly as intended.

It works even better with tighter tolerance.  Contrary to 
intuition, tightening tolerance (trtol, reltol) results
in fewer time steps.

Having said that ..  I like the work you are doing with euler
fallback.  You are fulfilling what I was thinking of when I created
the "trapeuler" and "trapgear" stubs.



reply via email to

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