On Tuesday 19 February 2008, a r wrote: > On Feb 19, 2008 6:19 AM, al davis <[EMAIL PROTECTED]> wrote: > > If there are no storage elements, there is no truncation > > error, but there is still "activity", and step control is > > still needed. > > I agree it doesn't work well in every case but for most > circuits (i.e. those with storage elements) truncation error > is a reasonable estimation of the circuit activity. You are > using it in trap method after all and it works quite well > (except for ringing which is an inherent "feature" of trap > method).
With noncritical circuits, a lot of things work, even if it is round-about. Unless you are doing critical analog work, where noise, distortion, and accurate timing are all important, truncation error is a round-about method. > > > For the future, there are plans to add node-voltage-change > > based time step control. > > That would be great, assuming it'd work reliably without > manual intervention. However, I see it as a great supplement > for the LTE based time step control, not a replacement for > it. It will be a supplement, not a replacement. > > Truncation error is only loosely related to circuit > > activity, usually too little, too late. That is why it is > > still possible to see trap ringing sometimes. > > What other simulators are using (spectre, hspice etc.)? > Whatever it is it works well enough for them - I've never had > to fiddle with their time step control options except for > some tricky circuits. Spectre is strictly voltage based. I think HSpice is now too, but it may have old spice truncation error based code still there. Most of the "fast-spice" simulators are voltage based only, and use Euler's method. > > Again, I am quite satisfied with the results of trap method. > There are some numerical artifacts but I can live with them. > I would only wish euler method to perform similarly well - > currently it is only usable for fixed time step transient > simulations. > > BTW, is it possible to enable LTE check in euler method in > the source code? If it's not very difficult I'd like to test > it a bit. In the development snapshot, e_storag.cc, line 250. Make it always false. Perhaps there should be an "option" to turn it back on, but it worked so badly that I decided it was better always off. While it worked so badly, I did prove that it was correct. Years ago, I did try to implement Gear's method, and ran into problems with automatic step control. Gear's method is easy when step size is uniform. It is manageable when step size is non-drastic and global. It is harder when step control is drastic and local, so I didn't go any farther. I started to do a mixed approach like Spectre does, so the framework for it is in place, but other things had higher priority. The usual approach is to resample with uniform step size, which increases the truncation error to essentially what you would get with Euler. The correct approach is to recalculate the coefficients. _______________________________________________ Help-gnucap mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnucap
