On Tuesday 07 January 2014, Felix Salfelder wrote: > this makes sense, as long as specifying euler is the only way > to make gnucap ignore the error (and if ignoring the error > is desirable somehow). i was assuming that "choice of > integration method" and "truncation error handling" are > different topics. i think they should be, see below.
To most users there are too many options. The method and step control really are related. Step control is not just truncation error. If the calculation of truncation error really was strictly mathematically correct, it might seem you would always want to use "trap", because when error is small it is always less then Gear or Euler. The problem is that it would lead to tiny steps that are not really needed. Recall .. Gear and Trap are second order methods. Error is proportional to some h^2. When h is small, h^2 is smaller. When h is big h^2 is bigger. On the surface we only care about h small. But really that is not so. There are times when we want to allow a large time step and HIDE the error with the intent of ignoring it. So we pick a method that presents its error in a manner suitable to be ignored even though it is large. That's Backward Euler. The error will always be such that the impulse response decays out faster than the real impulse repsonse. When the real impulse response decays so fast I can ignore it, the way Backward Euler presents its error is exactly what I want. If Euler is used with truncation error checking, its error will always dominate, and force time stepping much smaller than appropriate. > Gnucap System status > iterations: op=0, dc=0, tran=4053, fourier=0, total=5405 > transient timesteps: accepted=1169, rejected=183, total=1352. > > with .options method=euler (per device method selection does > not seem to be implemented) i get > > Gnucap System status > iterations: op=0, dc=0, tran=854, fourier=0, total=1139 > transient timesteps: accepted=256, rejected=29, total=285, > > which is effectively due to ignoring the error in c1. Per device method selection is partly implemented. I thought it was working at one time, but got removed? Two lines of code would put it back in the simple devices. (parse and print). Actually that was the intent, so you could mark the devices you don't care about, or indicate in the model source for complex models. The more important place was in devices generated by modelgen, so the strays can be there for model completeness, but only really matter sometimes. Probably what happened was that I was working on it and got called away and never got back to it. > now, what i have tried to work out is an adaptive method > selection. in the pulse & lowpass example, the pulse source > introduces discontinuities in the node voltages that break > trap in an obvious way. it totally makes sense to switch > back to euler in c1 (only) for those steps succeeding the > discontinuities -- *without* turning off step control... Interesting .. I see they all have a high number of rejections. Please try again after applying the pulse patch. I think your results are contaminated by pulse time step issues. I tried some things like that long ago, and eventually gave up and took a different path. The different path was to add another step control based on curve fitting, that is used when truncation error is meaningless. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
