For that option, you don’t have to do much. Use a parallel build of Xyce. Then, in the netlist have “.options linsol type=klu”, which tells Xyce to use a serial direct solver. If you don’t tell it this, it will attempt to use a parallel iterative solver, which for this size of problem isn’t the best choice.

Actually, I take that back. I initially just looked at the number of transistors, which is modest. But you have a very large number of passives. So, it is possible the iterative solver will compete at this size.

For the iterative solver you’ll want to make sure singleton removal is turned on at a minimum. I think this is default.

Unfortunately, the best choice of preconditioner (which is necessary for iterative solves) is very problem dependent and you may need to experiment a bit.

The device load phase, however, doesn’t require special options in general.

For this problem size, I’d experiment with different numbers of processors; you should see some benefits (I would think) out to at least 16 or more.

Also, even though the problem size is large by KLU standards, I would still try it. The cross over point between serial direct and parallel iterative solvers, in terms of performance is often close to this size. So KLU may still “win”, even at this size.

For general parallel solver guidance I’d read the user manual chapter “Guidance for running in parallel”. Most of the initial stuff I”m likely to say is in the chapter.

Is there a better serial direct solver tother han KLU for faster sim runs?

We haven’t made Pardiso part of our standard build, however.

There is a version that comes with the Intel MLK, and I think that is the one we’ve experimented with. But, Intel doesn’t develop Pardiso and there are more recent versions than that, which we have not tried yet.

Anyway, BASKER is faster the KLU. Using CMake Xyce can be built with it right now, but it wasn’t in the recent 7.6 release. It will be in the 7.7 release.

We will probably have a version of pardiso in 7.7 as well.