Hello <@U01SBMJT5BP> !! Shown below is the device ...
# xyce
Hello @Eric Keiter !! Shown below is the device count summary and number of unknowns in Xyce for a netlist. What is the best setting for parallel Xyce that should be used so the simulation is fast and efficient ? By setting I mean which solver to use or any other changes that should be made.
For a problem of that size, I would probalby use Xyce’s “parallel load, serial solve” option.
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.
@Eric Keiter Thanks for detailed response. I tried using KLU and it won. The sim completed using KLU. With the Xyce parallel default setting it showed error regarding rejectStep..
Is there a better serial direct solver tother han KLU for faster sim runs?
In theory, yes. For some circuits, the Pardiso solver, which is a threaded direct solver is faster.
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.
Okay! Got it.
PS. I wanted to also mention the BASKER solver. BASKER is a threaded direct solver we designed to be an update to KLU. That solver has been in development for a while, but is now ready for prime time. I didn’t mention it last week b/c I wasn’t 100% sure of the status.
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.
Great! Will surely try BASKER with 7.7 release.