[Top][All Lists]

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

Re: [Gnucap-devel] transient -- "trace" default

From: Felix Salfelder
Subject: Re: [Gnucap-devel] transient -- "trace" default
Date: Tue, 7 Jan 2014 15:58:08 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi Al.

On Wed, Jul 17, 2013 at 10:30:43PM -0400, al davis wrote:
> Most people go with the default, which is usually wrong.  Before 
> I change it, any reason not to?

no. i'm fine with trace=a.

somewhat related, the issues i had with step control:

- the spice pulse problem (see the other thread).

- the first step is chosen regardless of an ambiguous event. for example
V1 0 1 sin zero peak frequency=1k
.print tran v(1)
.tran 0 1 1 trace=a
i think, the initial step case in TRANSIENT::next should include a check
for _time_by_ambiguous_event < newtime.

- step control kicks in one step too late. in
double ELEMENT::tr_review_trunc_error(const FPOLY* p)
  }else if (_time[error_deriv] <= 0.) {
    // first few steps, I still know nothing
    // repeat whatever step was used the first time
    timestep = _dt;
  } [..]
i would have expected _time[error_deriv-1] <=0. in my understanding
there's nothing wrong with using the result of the initial DC analysis

- in TIME_PAIR STORAGE::tr_review(), i do not fully understand
  if (_method_a == mEULER) {
    // Backward Euler, no step control, take it as it comes
ELEMENT::tr_review_trunc_error seems to correctly implement the
truncation error in case order() == 1. unless i'm missing something, it
makes perfect sense to use it for step control.

i have been experimenting with this for a while. you might be interested
in how gnucap-uf [1] performs. particularly w.r.t the test suite.


    currently gnucap-uf-0.0.0-rc12.tar.gz

reply via email to

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