Xyce version 6.4 has been released.

[xyce-users]

The Xyce™ team is pleased to announce the release of Xyce™ Version 6.4.  This release fixes a number of bugs in Xyce™ 6.3 and includes improvements to existing features of Xyce™ 6.4. Please see the Release Notes for a complete list of new features and enhancements.

Highlights for Xyce Release 6.4 include:

  New Devices and Device Model Improvements

• VBIC version 1.3, 3- and 4-terminal variants (Q levels 11 and 12)
• MEXTRAM 504.11 with self-heating (Q level 505)
• New memristor device using the Yakopcic model
• Support for Reactive Power limits in the Power Grid Generator Bus model.
  

  Enhanced Solver Stability, Performance and Features

• The Kundert SPARSE linear solver has been added as a linear solver option.
• The netlist parser has been significantly refactored to reduce memory consumption and improve parsing speeds for large circuits.
• Improved Harmonic Balance (HB) robustness during the initial guess calculation.
• New Local truncation Error (LTE) criterions that use history information of signals improve time stepping for all time integrators.
• Oversampling capability for Harmonic Balance time domain output enables users to produce well-resolved time-domain outputs.
• Arclength continuation is now much more useful and robust.
• Sensitivity analysis can now allow multiple objective functions.
  

  Interface Improvement

• Power calculations supported for controlled-source devices (B,E,F,G and H).
• Support for additional .MEASURE statement syntaxes.
• New output options, that allow the user to suppress the header and footer of standard-format output files.
• Improved error handling during netlist parsing.
• Improved Harmonic Balance Output.
• Improved compatibility between Xyce (TM) and PSpice Digital Behavioral models, via support for the DIGINITSTATE option which sets the initial state of the Digital Flip-Flip and Latch devices.
  

For details, see the Xyce™ Users' Guide and the Xyce™ Reference Guide.

Also associated with this release are updates to the web site. The Frequently Asked Questions page has also been updated.

To obtain a copy of Xyce(TM) Release Version 6.4, please see the downloads section of the web site: http://xyce.sandia.gov/downloads

The team actively participates in an open forum for discussion of Xyce on Google Groups.  Details on how to join this forum are on the Documentation and Tutorials page of the web site,
http://xyce.sandia.gov/documentation/index.html.

Thank You,
The Xyce™ Team

You are receiving this email because you had previously expressed interest in Xyce™.  If you do not wish to receive these emails then please contact us at xy...@sandia.gov, and you will be removed from our mailing list.

Sandia National Laboratories is a multi-program laboratory managed and operated by Sandia Corporation, a wholly owned subsidiary of Lockheed Martin Corporation, for the U.S.  Department of Energy's National Nuclear Security Administration under contract DE-AC04-94AL85000.

PSpice is a registered trademarks of Cadence Design Systems, Inc.

[Marcel Hendrix]

> The Kundert SPARSE linear solver has been added as a linear solver option.

Were any tests done to determine the efficiency of this solver with respect to

the alternatives available in Xyce?

-marcel

[xyce-users]

Marcel:

Yes, the Xyce team has done a systematic study of the relative performance of KSPARSE vs. KLU (the two direct solver options in Xyce).   Unfortunately, the short story about the optimum choice is that "it depends."   Which solver works better is completely problem-dependent,  so you just have to try it and see if there is an improvement.

The longer story:

KLU uses Dulmage-Mendelsohn reordering to get the block triangular (BTF) form.  For it to work, there needs to be an assymetry in the DC operating point Jacobian matrix. It can often be hard to predict which circuits will have this property.  In general circuits that are based on older MOSFET models (like the BSIM3) will often have this property.  Circuits based on new surface potential MOSFET models (like the PSP and EKV) will not.   Circuits that are NOT MOSFET circuits will usually be symmetrical, although sometimes the BTF algorithm will still find a reduction.
 
Basically the only way to know for sure is to run BTF on a circuit matrix and see what happens.  If BTF produced a single irreducible block, then BTF failed and KLU won't perform that well and there is a reasonable chance that Ksparse will do better.

Ksparse uses Markowitz reordering, which is more generic.  The drawback of Ksparse is that it is a little less robust.  Also, the original spice3 version had a lot of inefficient bottlenecks in it, separate from the reordering issue.  One of the Xyce developers fixed a lot of these bottlenecks several years ago, so the Ksparse solver in Xyce is a one-off version.  It will perform better than the original Ksparse.  Even so, there are still inefficiencies in KSPARSE relative to KLU just from the way it's written.

One of our developers has done studies on several circuits of interest to our internal customers, and for many of them Ksparse is a faster choice. Also, for the simple charging circuit that you reported here some time ago, Ksparse is faster.

It is because the optimal linear solver is so problem-dependent that we have decided to include more solver options in the default build.  In releases of Xyce prior to 6.4, KSPARSE was available but only if a non-default compile time option was specified ("--enable-ksparse" needed to be added to the configure line prior to building).  KSPARSE is now available in the default build, and can be selected either with the "-linsolv ksparse" command line option, or the ".options linsol type=ksparse" netlist directive.

We hope that gives you the kind of information that you wanted.

Thank you,
The Xyce™ Team.

[Marcel Hendrix]

On Saturday, January 23, 2016 at 11:12:26 PM UTC+1, xyce-users wrote:

> On Saturday, January 23, 2016 at 1:52:52 AM UTC-7, Marcel Hendrix wrote:

>> Were any tests done to determine the efficiency of this solver with respect to
>> the alternatives available in Xyce?

[..]

> Basically the only way to know for sure is to run BTF on a circuit matrix and

> see what happens. If BTF produced a single irreducible block, then BTF failed

> and KLU won't perform that well and there is a reasonable chance that Ksparse

> will do better.

I notice that you do not say that KLU is better than Ksparse for large netlists.

NGSPICE uses Ksparse, but has KLU. Unfortunately this KLU implementation

does not support behavioral sources, and I use these all of the time. The *small*

circuits that I have tried (without behavioral sources) do not show remarkable

speedups. However, this may be because factoring and solving time is (for the

circuits that I am interested in) mostly dominated by loading the circuit matrix.

[I'll post a worrisome exception to this rule in a another thread.]

> One of the Xyce developers fixed a lot of these bottlenecks several years

> ago, so the Ksparse solver in Xyce is a one-off version. It will perform better

> than the original Ksparse. Even so, there are still inefficiencies in KSPARSE

> relative to KLU just from the way it's written.

Obviously, I am now going to ask if this improved Ksparse is available in

source form, if it is plug compatible with Kundert's sparse1.4b (latest) or

1.3 (as used by NGSPICE), and if there is hope for "porting back" ?

> We hope that gives you the kind of information that you wanted.

Many thanks for your detailed and knowledgeable reply.

-marcel

[xyce-users]

A few quick answers, below....

On Sunday, January 24, 2016 at 4:46:26 AM UTC-7, Marcel Hendrix wrote:

I notice that you do not say that KLU is better than Ksparse for large netlists.

NGSPICE uses Ksparse, but has KLU. Unfortunately this KLU implementation

does not support behavioral sources, and I use these all of the time. The *small*

circuits that I have tried (without behavioral sources) do not show remarkable

speedups. However, this may be because factoring and solving time is (for the

circuits that I am interested in) mostly dominated by loading the circuit matrix.

[I'll post a worrisome exception to this rule in a another thread.]

KLU should generally be better than Ksparse for large netlists.  9 times out of 10, it should be a better choice in any case. The original version of Ksparse was particularly bad with respect to large circuits, actually.  The modified version in Xyce is a little better, but not as good as KLU.  In most respects, KLU is a better solver and that is why it has been our default since the early 2000's.   However, it does have the one weakness related to matrix symmetry, so occasionally our modified version of Ksparse beats it.

We do not have the problem with behavioral sources, by the way.  In Xyce KLU will work on all devices.

 

> One of the Xyce developers fixed a lot of these bottlenecks several years

> ago, so the Ksparse solver in Xyce is a one-off version. It will perform better

> than the original Ksparse. Even so, there are still inefficiencies in KSPARSE

> relative to KLU just from the way it's written.

Obviously, I am now going to ask if this improved Ksparse is available in

source form, if it is plug compatible with Kundert's sparse1.4b (latest) or

1.3 (as used by NGSPICE), and if there is hope for "porting back" ?

The modifications made to Ksparse were actually done many years ago and this is no longer an active area of development.  I do not think that it would be "plug compatible".   So, the short answer is "no".

There is a new direct solver under development, which we're hoping will be better than both Ksparse and KLU.  But I can't give a precise timeline for its deployment  in Xyce yet.

 

Many thanks for your detailed and knowledgeable reply.

No problem.