I still need to answer your other mail. I started, but some require more time to get it right.
On Saturday 06 June 2009, henrik johansson wrote: > The only general and practical solution to the problem I > think is to go from NA to MNA forumulation, at least for the > inductors. I don't think this would be so difficult. Inductors do use MNA when the _c_model flag is set. Always using MNA for inductors results in a significant speed penalty for some types of simulations, particularly signal integrity related. 2:1 slowdown is typical in circuits with a large number of inductors. There are also matrix issues that may or may not matter in any particular situation. For mutual inductors, the MNA formulation is the only way that works in general and still keeps the expand process simple. As to speed, true nodal analysis is faster for two coupled inductors, they are about equal for three coupled inductors, and MNA formulation is faster for four or more. If your circuit has just a few mutual inductors, this doesn't matter. The difference becomes apparent when doing large signal integrity simulations. That is one of the reasons for adding expand_first and expand_last, to be able to make those decisions in a sensible way. MNA is not really a different algorithm. All it means is that some devices have an internal "node" where the "voltage" is really a "current". The only difference is in the device models. You get the same effect with other devices, such as transistors with resistance in series with the terminals. It is traditional to think of the state vector as all voltages, but it isn't really. > The issues that comes to mind are: current state vector has > to be added to SIM, coil device has to be re-written, > convergence criterions have to be changed, current probes > should use the current state. Isn't all that part of the inductor model? Convergence criterions and step control for inductors are based on flux, current, and inductance (dflux/dcurrent). _______________________________________________ Gnucap-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnucap-devel
