On Thursday 29 November 2007, a r wrote: > OK, I've found the solution: > > .probe tran v(in) v(n1) v(out) > > .dc > .tran 1n 4u >out.dat > > Looks like .probe and .print commands work same in this > context. Before I was trying to redirect the .print's output > to the file instead of redirecting the analysis (.tran) > itself.
They are the same. There is a historical reason for it. It was originally "probe" only, then "print" was added for "spice compatibility". At that time, the "spice compatibility" goal meant that it would be possible to make files that worked in both. It was never intended for gnucap to be like a spice clone. There are features of the gnucap way that I cannot give up. > BTW, I am getting pretty strong numerical ringing in this > analysis. AFAIK, gear method is not yet implemented. Any > chance for this? For now, try "method=euler". The Gear method is almost never the best choice. It is popular because it is often the second choice. If trap is giving you trouble and Gear would fix it, Euler would be more accurate. If Euler is not accurate enough and Gear is better, trap is even better. Specifying Euler disables the truncation error part of time step control. This is what you want. If you really want it to be accurate, tighten the tolerances to make it stop ringing. It may seem counterintutive that a first order method would be more accurate than a second order method, but in this case, it's true. Consider this: First order means error is proportional to something quantity I will call "h". Second order means error is proportional to h^2. Which one is smaller depends on the value of h. People think the higher order method is more accurate because when h is small, h^2 is even smaller. They forget that when h is large, h^2 is larger. For accurate simulation, h is small. When you see trapzoidal ringing, h is large. The actual error with Gear's method is higher than trap (more correctly "Huen's method"), but it is in a form that is less apparent. If you want reasonable results with a time step that is too large for the time constant, use Euler. This is a reasonable request. Strays often are in this category, you would like to ignore them. Euler errs reliably in the direction of ignoring them. As to any chance for adding the Gear method ,,,, I have no objection to including it as an option, but I have other higher priorities for now. If you (or anyone reading this) want to add it, and can show that it is correct, I will welcome the addition. It's not as simple as it seems. It is harder in gnucap than in Spice, because time stepping in Spice is global. All devices share the same set of time steps. In gnucap, time stepping is local. Different devices can have different time steps. The issue for Gear is computing the coefficients with unequal steps, When stepping is uniform, you can look up the coefficients in a table, It's easy. When stepping is non-uniform, the coefficients must be calculated, possibly for every step, and since time history is local, for every device. If you forget about this, you may not see the error, because usually stepping is synchronous, and will hide the bug. Then occasionally you get a spike of really strange results that can't be explained. One possibility I have considered is a Spectre-like "trap-gear" or "gear-euler" method, where it switches methods on the fly, using Gear when it is easy and switching to something else when it causes trouble. I'm getting technical here ...... It is because of these subtleties that I didn't do it already. _______________________________________________ Help-gnucap mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnucap
